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