Solving mt_allocator's static initialization ordering problem
Paolo Carlini
pcarlini@suse.de
Wed Jun 30 11:47:00 GMT 2004
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.
More information about the Libstdc++
mailing list