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

[Carlos O'Donell]

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.

* Discuss the ISO C11 implications.

  ISO C11 wording in 7.14.1.1 p5:
~~~
If the signal occurs other than as the result of calling 
the abort or raise function, the behavior is undefined if 
the signal handler refers to any object with static or
thread storage duration that is not a lock-free atomic
object other than by assigning a value to an object 
declared as volatile sig_atomic_t, or the signal handler 
calls any function in the standard library other than 
the abort function, the _Exit function, the quick_exit 
function, or the signal function with the first argument
equal to the signal number corresponding to the signal
that caused the invocation of the handler. Furthermore,
if such a call to the signal function results in a 
SIG_ERR return, the value of errno is indeterminate.252)
~~~

  Will our TLS variables become lock-free atomic objects?

* Post the patches for an implementation and allow time
  for upstream review and testing on various architectures.

  * Provide detailed performance implications of the patches.
    Preference is to have some data that shows that standard
    uses of TLS are not negatively impacted.

  * Provide changes to the manual to explain that accessing
    thread local storage is now async-signal safe and
    will be going forward.

  * Consider providing some way to assure that old programs
    using TLS in a signal handler fail safe. If it can't
    be assured, explain why not.

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

  * Provide proof that another arriving signal that interrupts
    the dynamic TLS setup won't cause the setup to fail.

  * Provide proof that another thread calling fork that
    interrupts the dynamic TLS setup won't cause the setup to
    fail (similar to re-entrancy requirement, but should be
    considered separately).

  * Provide proof that an asynchronous cancellation of
    the thread in the singal handler doing the dynamic TLS
    setup won't cause the setup to fail (again similar to
    re-entrancy ...).

* Work with the community to ensure consensus around an
  acceptable solution.

Please don't misinterpret my request as throwing up a road-block
to this work. I would like to see a high quality implementation
of TLS variables that supports use in signal handlers, but I do
not want to see it impact existing uses, or provide only half
of what is required.

And do not doubt that I am lazy and dumb :-)

Cheers,
Carlos.