Async-signal-safe access to __thread variables from dlopen()ed libraries?

[Joseph S. Myers]

On Fri, 20 Sep 2013, Carlos O'Donell wrote:

>   Will our TLS variables become lock-free atomic objects?

If they are declared with an _Atomic type for which the corresponding 
ATOMIC_*_LOCK_FREE is defined, they should be.

>   * Similarly provide symbol versioning to prevent a new
>     program from being run on an old glibc that doesn't
>     provide AS-safe TLS vars.

Not needed.

However, since there are two separate but related problems (AS-safe access 
to TLS variables, and ensuring allocation failure is reliably indicated by 
pthread_create or dlopen failure, rather than happening on access to a TLS 
variable when there is no good way to return a failure status), 
considering how the design for fixing one problem relates to the other 
problem (e.g. whether it introduces new code that would need to be removed 
again when fixing the other problem) is certainly relevant.

I think both problems are appropriate to fix (and should have separate 
bugs opened for them in Bugzilla, if not already open).

-- 
Joseph S. Myers
joseph@codesourcery.com