Subject: Re: [boost] [Boost-users] Boost.Pool - Are you using this library, please can we have your input?
From: Jeremiah Willcock (jewillco_at_[hidden])
Date: 2011-01-18 13:13:54
On Tue, 18 Jan 2011, Paul A. Bristow wrote:
> Boost.Pool is the subject of a 'make-over' by Boost.Guild.
> (This is some of a test-bed for a process of revision of older, perhaps
> orphaned, libraries using the relative safety of the sandbox).
> We are now considering some better tests, and perhaps some enhancements to
> the code.
> We'd like input from users about:
> 1 Things missing or wrong from the docs. More up to date references?
> 2 Things missing (or don't work well) from Pool.
Using pools with small allocation chunks (to get behavior like malloc/new)
is very slow. It might be nice to have a type of pool that keeps
variable-sized blocks, like current malloc implementations do.
> 3 New things that you would like (this is not a promise!).
The ability to store the pool metadata outside the pool itself. The case
where one would use this is when the pool is being used to allocate a
special kind of memory, and the pool metadata (headers and free list)
doesn't need to be in that kind of memory.
A shared_ptr deleter for objects allocated from pools.
A pool UserAllocator that gets its memory from another pool (to allow a
pool of large blocks to be broken into smaller pieces to store individual
A thread-safe pool (preferably including lock-free or semi-lock-free
algorithms when possible).
> 4 Examples of your use. Perhaps you built some during your development
> that could be used?
I was using a pool (simple_segregated_storage) to manage pages of memory
that are registered with GASNet for message passing. In its fastest mode,
GASNet requires a contiguous block of memory to be registered when the
program starts, and I used a pool to allocate data structures in this
block. Additionally, a pool is a safe way to allocate memory in a signal
context (since it is possible to lock accesses to the pool), while
malloc/... are not signal-safe.
-- Jeremiah Willcock
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk