httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ben Hyde <bh...@pobox.com>
Subject Re: heavy and lightweight pools...
Date Mon, 25 May 1998 14:24:43 GMT
>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've working around this in a few ways.  I teardown and rebuild my
persistent connection state from time to time - just on general principles.
I copy (GC) the pool to a new one in some cases.  I like discarding the
entire pool - it makes the leak problem much more tractable and coding
more casual.  I manage my own heaps for pools of data structure elements,
and my own heaps for pools of larger variable sized things.

I'm ambivalent about adding a richer set of operations to the existing
POOL abstraction.  It's a very pretty bite sized thing right now.

The only operation I've desired was the ablity to assign it a block of
memory to manage (i.e. the block I obtained via memory mapping).  Then
I could use it for interprocess I/O and for persistant data storage.

 - ben hyde



Mime
View raw message