RE: [boost] Pool Review: Design

From: scleary_at_[hidden]
Date: 2000-12-04 10:21:34

> [Gary Powell]
> the pool can't go away until all of the memory allocated of a specific
size
> does. It's not exactly what I would have wished for. Does anyone else have
> any specific data on this sort of shared pool technique?

Actually, when using the pool allocator interface, the pool won't go away
until after main() exits :).

There are two ways around this:
  1) Add a function to sized_pool to allow freeing of memory blocks that
don't have any chunks.  This could also be useful to call in low-memory
conditions.  This is on the "future feature" list.
  2) Try to implement another allocator interface based on a "shared pool"
-- literally, it may be possible to base it on shared_ptr<sized_pool>.

> [Gary Powell]
> I've seen it used
> by a replacement for malloc on a system wide memory replacement. Am I
> wishing for things I didn't really want?

I don't think you want that :).  Pool is best used with large numbers of
small size allocations/deallocations.  It's not a good general-purpose
solution.  Note also that I believe all Linuxes by default use Doug Lea's
malloc() now, which has a large number of static pools for small object
allocation already -- any pool-based malloc replacement would probably not
benefit that system.

        -Steve