[boost] [pool] Calling all library designers: The future of Boost.Pool???

Subject: [boost] [pool] Calling all library designers: The future of Boost.Pool???
From: John Maddock (boost.regex_at_[hidden])
Date: 2012-07-17 14:35:40

As one of the last people to try and do any maintenance of Boost.Pool I feel 
I should try and start some discussion here on it's future.

First off some random thoughts based on my last experiences with this 
library:

* It should be simple, but it's confusing.  In particular the difference 
between ordered and unordered pools is not particularly intuitive, but IMO 
the distinction between the various components, and what should be used 
where is also poor.
* I believe the decision to support both ordered and unordered pools in the 
same interface was a mistake.  At the very least it's potentially error 
prone in use, but it's also inefficient.  It looks to me that this, along 
with the allocators provided, were a classic case of feature creep 
post-review.  I'm sure they sounded like good ideas during the review, but 
in practice a smaller more tightly focused library might actually be better.
* It's not clear that the claimed performance improvements are actually 
there in practice (any more).  This is partly due to compiler and std lib 
improvements, partly due to feature creep in Boost.Pool.  Some bug fixes 
have had a negative effect too - however needed they may have been for 
correctness.
* Many of the existing bug reports were deliberately left "in limbo" because 
there was no obvious/easy way to fix them without compromising Boost.Pool's 
core mission (providing fixed size blocks of memory really fast).
* There have been many changes to the standard, compiler technology, and to 
Boost's best practices since the library was designed, many of which would 
result in a different design today, but also different requirements today 
(per instance allocators in containers for example).
* In no way do I want to be lumbered with maintaining Boost.Pool and in any 
case I don't believe it's really fit for purpose any more [1].

So..... in an ideal world, I'd like someone to step up to the plate and 
design it's replacement.... yes a whole new Pool2.

Off the top of my head, here's my wish list:

* There should be a very small, very focused (i.e. fast) core that provides 
fixed sized blocks of memory.  Nothing more.
* Thread synchronization when needed (template param?) should be via 
lockfree programming wherever possible.  Indeed a simple pool like this, is 
pretty much the poster child for lock-free-programming.  And of course we 
have Boost.Lockfree now.
* There should probably be a heap implementation for variable sized 
allocation requests.  I'm assuming that this can't be done lockfree(?).
* Allocators: both singleton and stateful allocators should be provided 
(templated on pool type?).  But there's a trick here: many containers only 
allocate fixed size blocks, but we have no way of knowing what that size is 
upfront at compile time.  Connecting the allocation request to the correct 
pool interface in an efficient manner is pretty tricky here, especially if 
99% of allocations are of fixed sized, but there are a few odd-sized control 
blocks also allocated.  In any case, all allocations should come from the 
same underlying block of memory, even if they're for different types/sizes.
* Both pools and allocators, should be able to accept a single fixed sized 
block of memory (from wherever) and divide it up to clients.  A good example 
for this use case is an arena-allocator: a stateful allocator whose memory 
all comes from the stack, no thread synchronization required.  Containers 
using such types can be blisteringly fast compared to regular allocators, 
particularly when using a scoped container for just a few manipulations. 
Ideal for use with C++11 containers or Boost.Container.

Hopefully others will chime in here with their requirements as well.

Cheers all, John.

1) This doesn't preclude applying *trivial* fixes to Boost.Pool, but I 
genuinely believe that big changes are more likely to be counterproductive 
at this point.