[cxx-abi-dev] thread_local CONstructors

[Jason Merrill]

On 09/24/2012 10:57 AM, Jakub Jelinek wrote:
> You mean
>    static thread_local bool done;
> right?

Yes, right.  Though you don't need the 'static' because 'thread_local' 
implies it in function scope.

> Though perhaps one could register just the TLS dtor
> for the whole TU, and let it call the individual dtors in the right order
> (and check the done TLS flag, if false and nothing has been initialized
> in the current thread, just don't do anything).

This would be wrong if the init function for another TU gets called in 
the middle of this one.

>> Unfortunately, since there is no way to tell whether a thread_local
>> variable with external linkage has a dynamic initializer in another
>> TU, we need to do the a1 to a1_f() transformation even for variables
>> of POD type that are statically initialized.  I don't see a way to
>> avoid this except doing POD initialization at thread creation time
>> rather than lazily, which means significant changes outside the
>> compiler.
>
> That would be a big problem with dlopen when there is more than
> one thread in the process at the time when dlopen is called and one of the
> dlopened libraries has some thread_local vars that need constructing.

True.  I suppose we would have to reject the dlopen in that case, so 
doing lazy initialization is probably better.  It just makes me sad to 
have a runtime penalty even for variables that are statically initialized.

> FOr destruction of thread_local vars, guess we can just make the
> corresponding libraries non-dlclosable dynamically (as running destructors
> in all threads upon dlclose would be a huge pain).

Would implicitly adding RTLD_NODELETE have the semantics we want?

Jason