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

[Rich Felker]

On Fri, Sep 20, 2013 at 01:41:37PM -0400, Carlos O'Donell wrote:
> On 09/20/2013 10:25 AM, Ian Lance Taylor wrote:
> > Clearly it is technically infeasible to use some features from a
> > signal handler.  I'm not going to waste time suggesting that it be
> > possible to call malloc from a signal handler.  However, making it
> > safe to use __thread variables in a signal handler is not technically
> > infeasible.  If we fail to support it, we're just being lazy.
> 
> Good programmers are both lazy *and* dumb.
> 
> Being lazy and dumb I don't want to maintain a complex TLS
> implementation, and being dumb means I can't.
> 
> Therefore to overcome my lazy dumbness I suggest the following:
> 
> * Discuss some alternative solutions to the problem at hand 
>   and why they were rejected.

Alternatives to which problem? Needing thread-local data in a signal
handling context? Formally, the only solution I see is using the
getpid() and &errno as keys into an on-disk file containing the
thread-local data. This is extraordinarily ugly.

> * Discuss the ISO C11 implications.
> 
>   ISO C11 wording in 7.14.1.1 p5:

The ISO C text on signal handlers is rather irrelevant. In plain C,
there is nothing useful you can do from a signal handler whatsoever,
nor is there anything useful that can cause a signal. POSIX specifies
a lot more you can do with signal handlers (it defines many of the
undefined aspects), but the current POSIX spec actually has lots of
bugs; see:

http://austingroupbugs.net/view.php?id=728

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

I don't see how this question is related at all. Atomic in the C11
sense has to do with synchronization between processors, not signals.
The memory model for access to objects from signal handlers should not
define the behavior when the signal handler accesses an object whose
modification the signal handler interrupted, except for objects of
type sig_atomic_t or character types (I added the latter because the
C11 memory model already requires byte-granularity write operations),
but otherwise (as long as the signal handler is sequenced to avoid
such access, e.g. using signal masks) access to arbitrary objects from
signal handlers should be unrestricted.

Rich