Re: [boost] [pool] segfault (fun with static initialization ordering)

From: Joaquin M Lopez Munoz (joaquin_at_[hidden])
Date: 2008-07-15 09:41:39

Chris Newbold <Chris.Newbold <at> mathworks.com> writes:

> 
> > From: boost-bounces <at> lists.boost.org [mailto:boost-bounces <at>
lists.boost.org]
> > On Behalf Of JOAQUIN M. LOPEZ MUÑOZ
> > Sent: Friday, July 11, 2008 11:35 AM
> 
> > BTW, have you tried the fix I was proposing?
> 
> Not yet. I'm on vacation this week, but I will try it as soon as possible.
> My only concern is whether referencing singleton_default from the
> constructor for fast_pool_singleton will guarantee proper initialization
>  ordering.
> 
> 3.6.2 doesn't really shed any light on how ordered and unordered
> initialization may be coupled. There isn't, for example, any expressed
> guarantee that non-locals will be initialized prior to first reference.

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).

The non-local object involved in singleton_default<T>, namely
singleton_default<T>::create_object is there to guarantee that
singleton_default<T>::instance() is invoked, and thus the singleton created
in dynamic initialization time *if no one has done it before*.

Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo