Boost logo

Boost :

From: Chris Newbold (Chris.Newbold_at_[hidden])
Date: 2008-07-23 07:37:40


> From: boost-bounces_at_[hidden] [mailto:boost-bounces_at_[hidden]]
> On Behalf Of Joaquin M Lopez Munoz
> Sent: Tuesday, July 15, 2008 9:42 AM

> There is no such guarantee indeed, but the fix does NOT rely on
> initialization
> rules for non-local objects, but on the initialization rules for *local*
> objects with static storage duration (6.7/4): the singleton is a local
> static
> object inside the function singleton_default<T>::instance(), which is
> explicitly invoked inside fast_pool_allocator ctors via
> singleton_pool<...>is_from() (if you apply the fix, that is).

Quite right. I now agree your suggested fix is completely sound.

And, in fact, making your suggested fix re-orders the construction of the pool and allocator objects as expected. I tried the experiment with GCC 4.1.2.

The next step is for me to audit the remainder of the pool library and see if there are other clients of singleton_pool which are subject to the same potential failure mode.

Are there any "better" suggestions out there for handling the singleton needs of the pool library?

-Chris


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk