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
> 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
> 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?