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

[Florian Weimer <fweimer at redhat dot com>]

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