Re: Solving mt_allocator's static initialization ordering problem

[Paolo Carlini <pcarlini at suse dot de>]

Hi Brad

and, first, thanks for your anaylsis.

> All I could come up with was this hack of looking to see if
> _S_options is still uninitialized in _S_initialize(), and if so,
> running an in-place construction to use the default values.
> It's ugly, but it does work.  Is it safe?
>  
Seems not so bad to me, frankly. In any case, it should be moved *before*
the lines

 if (_S_options._M_force_new)
    return;

and, more important perhaps, why checking _S_options._M_align at all?
Can't we execute the placement new unconditionally, removing a bit of
fragility? Benjamin, what's your take on this? Perhaps we should be careful
about alignment issues (compare the existing placement new in locale and
iostreams)

> I didn't go any further with change because I hit upon a couple of
> questions that I couldn't answer:
>
> 1. When exactly are are you allowed to call _S_set_options() and what
>    exactly will it do?  It would seem you have to be after the static
>    initialization of _S_options, but before the first allocation.
>    Tricky.  
>
> 2. Is there a cleaner way to do the same thing without reworking how
>    the tunable parameters are set?  Perhaps things could be changed so
>    _S_options is _only_ initialized by this lazy init?  This
>    probably depends on the answer to question 1.
>  
All nice and interesting questions. In particular, I wonder why _S_*_options
are *private*?!?

Paolo.