* Florian Weimer via Std-Discussion:

> If I read [basic.start.term] p3 correctly, destructors are essentially
> called in the reverse order of constructors. I assume implementations
> still can in theory eagerly call constructors for thread-local variables
> on thread start if they want to avoid the necessary per-thread
> bookkeeping. However, that possibility does not exist for thread-local
> variables that are defined in run-time loaded modules (think dlopen).
> (The dynamic loader cannot switch to the appropriate threads and call
> the constructors there, the calls have to happen on demand on the
> respective thread.) These issues around dynamic code loading are out of
> scope for the standard, but that does not make them go away.
>
> Anyway, for on-demand initialization of thread-local variables, an
> implementation has to track the construction order for on-demand
> initialization of thread-local variables, so that the destructors can be
> called in the reverse order. This typically increases the amount of
> thread-local storage for such variables by 50% to 100% (because the
> order is thread-specific, and it has to be recorded somewhere).
>
> What's the reason that this requirement was put into the standard?
> Destruction order of singletons is tricky, and the suggested order does
> not work in all cases. (If I recall correctly, Andrei Alexandrescu
> discusses the surrounding issues extensively in Modern C++ Design, in
> the context of regular, non-thread-local singletons.)

No takers?

Is there a private forum where I could submit this?

Thanks,
Florian