Re: [boost] [pool] Improvements to boost.pool

Subject: Re: [boost] [pool] Improvements to boost.pool
From: Paul A. Bristow (pbristow_at_[hidden])
Date: 2012-06-14 08:33:09

> -----Original Message-----
> From: boost-bounces_at_[hidden] [mailto:boost-bounces_at_[hidden]] On Behalf Of DUPUIS
> Etienne
> Sent: Monday, June 11, 2012 6:46 AM
> To: boost_at_[hidden]
> Cc: DUPUIS Etienne
> Subject: Re: [boost] [pool] Improvements to boost.pool
> 
> Now that changes have been made to boost::pool in the sandbox, what is the next step to get them
> approved/amended/rejected ?
> 
> Regards,
> Étienne
> 
> 
> 
> -----Message d'origine-----
> De : DUPUIS Etienne
> Envoyé : mercredi 16 mai 2012 12:43
> À : boost_at_[hidden]
> Objet : [pool] Improvements to boost.pool
> 
> Greetings,
> 
> In the boost sandbox, under the /pool folder, I have committed a few small improvements and a few
fixes
> for open tickets. Here is what I have changed :
> 
> 1. I added boost::static_pool, a pool whose maximum size is known when initializing the pool; in
which
> case all memory is allocated when calling the constructor. This is useful for software that must
manage
> memory with great care. The implementation is a simple subclass of boost::pool. In the same vein,
I also
> added boost::static_object_pool.
> 
> 2. I also added boost::array_pool, a pool whose maximum size is known at compile time. The
array_pool
> object hence already contains all memory it needs. Same for boost::array_object_pool. I am not
sure that
> this is really useful and I am not sure I have picked a good name for it.
> 
> 3. I handled ticket #3789 (https://svn.boost.org/trac/boost/ticket/3789). In short, releasing
objects from a
> boost::object_pool was O(n) instead of expected O(1) and this constraint was required to keep the
pool
> ordered so that the destructor of object_pool could destroy all objects that the calling program
did not
> released. To solve this problem, I created an O(n log n) function which orders an unordered pool,
a
> function that I called in the destructor. Thus, with my modification, releasing objects is O(1)
and the
> destructor is O(n log n), or O(1) is the calling program was kind enough to release all objects.
Although this
> does not change the API, it could have a negative impact on software that allocate large number of
> objects (using object_pool) but that never releases them. However, my modification greatly
improves
> programs who repeatedly requests and releases objects. This modification also handles ticket #6610
> (https://svn.boost.org/trac/boost/ticket/6610).
> 
> 4. I added a pool.get_size() function (https://svn.boost.org/trac/boost/ticket/6865) that returns
the
> current number of elements/objects for which the pool has allocated memory.
> 
> 5. I clarified the meaning of the 'max_size' parameter, a recent addition to limit the amount of
memory a
> pool can allocate with a single call to the allocator. See ticket #6867
> (https://svn.boost.org/trac/boost/ticket/6867) for details.
> 
> 6. I fixed miscellaneous minor tickets : #5902 (division by zero when requesting null sized
buffers), #6561
> (crash when releasing a null pointer), #6710 (integer overflows and possible crashes when
requesting too
> many elements).
> 
> 7. I added test cases for all modifications. I manually tested each case on Windows and used bjam
on
> Linux, although I am not exactly sure that bjam did anything as it did not even report which test
it ran.
> 
> 8. I still need to update the documentation. Before doing that, I thought that I should submit my
changes
> to the Boost community to see whether they are approved or not. And more prosaically, I still need
to
> figure out how to generate the said documentation !

I can help with the docs (I translated the old Pool docs) but I have no more than superficial
knowledge of Pool.

But I am on holiday for a while, so mail me privately and I will reply when I get back.
 
> Now that these changes have been made in the sandbox, what is the next step to get them
> approved/amended/rejected ?

Before any changes can be moved to boost-trunk, IMO we need input from pool library users.

Some of the changes look very useful, but may break old code?

Ask on boost-users list for support?

Paul

---
Paul A. Bristow,
Prizet Farmhouse, Kendal LA8 8AB  UK
[phone]  07714330204
pbristow_at_[hidden]