>  I.e., I'd like to be able to set things
> up in palloc() given to pool_create() and then have this field
> survive subsequent pool_get()/pool_put().  The current implementation
> supports this if the the offset of the field within an item
> is large enough (since the pool allocator uses the first part
> for a free list).  Would it be reasonable to specify that
> pool(9) should behave this way, i.e., that all memory within
> an item beyond a certain offset is left undisturbed?  Or is
> this just too hacky?


This type of functionality seemed to be the primary motivation in the
Bonwick slab paper which describes the use of constructor and destructor
functions to manage the state of objects. 

I thought about doing this by layering a persistance module on top of
the plain memory allocator.  I'm not convinced though that this is
the best approach, since there's going to be a lot of overlap with
the current pool code. Merging this into the pool code seems
relatively straightforward.

-pk