Boost logo

Boost Users :

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


Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net