heavy and lightweight pools...

[Dean Gaudet <dg...@arctic.org>]

I finally convinced myself that we can't go on with just the "light" pools
we have now... dunno if anyone else thought this was obvious, it didn't
occur to me for a while.  Specifically I think we're going to need pools
with a free() function in the future.  A few examples: 

- A shared cache, say a shared mmap() cache, needs some method of
bookkeeping that's persistant, and used by multiple threads, and which
will need to have objects free()d occasionally.  Suppose it uses a hashed
linked list... if it decides to drop 20 objects from the cache when it
adds one new large object we may not want to keep the 20 object's storage
allocated.

- Implementing a connection-based service, such as IMAP, which may persist
for a long time, could result in many changes to per-connection data (such
as the current folder/message number), which over time would waste lots of
memory.

I still think that what we have now, call them light pools, are the answer
for most of everything in HTTP and (anonymous) FTP for example. 

I'll probably do something along these lines when I implement the mmap
cache in apache-nspr... it'll all be hidden behind the pool * (using
indirect function calls, yeah yeah, just like C++ would do if it were a
class).

Dean