Re: [Boost-users] Boost.Pool - Are you using this library, please can we have your input?

Subject: Re: [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).
>
(snip)
>
> 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 
objects).

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