[RFC PATCH glibc] pthread_setspecific: Provide signal-safety across keys

[Florian Weimer]

On 10/19/2017 11:44 AM, Szabolcs Nagy wrote:
> On 17/10/17 23:19, Florian Weimer wrote:
>> Global-dynamic currently has lazy allocation for each thread, so a
>> library constructor is not good enough to ensure initialization.  We
>> probably want to fix this, but major language standards say that TLS
>> access from signal handlers is undefined, so it's not even a real bug.
> 
> the relevant standard for a libc implementation is iso c which has
> 
> 7.14.1.1p5
> "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."
> 
> i.e. lock-free atomic and volatile sig_atomic_t tls access should work.

For us, it depends on the TLS model.  Async-signal-safe TLS access is 
considered unimplementable in general, which is why C++ makes it undefined:

“
\pnum
\indextext{signal-safe!evaluation|see{evaluation, signal-safe}}%
An evaluation is \defnx{signal-safe}{evaluation!signal-safe} unless it 
includes one of the following:

\begin{itemize}
[Â…]
\item
an access to an object with thread storage duration;
”

Thanks,
Florian