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

[Florian Weimer <fweimer at redhat dot com>]

On 10/19/2017 01:04 PM, Szabolcs Nagy wrote:
> On 19/10/17 11:37, Florian Weimer wrote:
> > 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,
>
> musl implements it: you just have to allocate tls for
> all dsos and all threads in dlopen and pthread_create.
> (if unbounded dlopen/dlclose calls are supported then
> it's a bit trickier since dtv slots need to be reused
> then, but should be possible in principle)

We have received guidance that this is not desirable for all TLS usage 
scenarios.  Some applications might not want to allocate backing storage 
for the full set of TLS variables for those threads which do not need 
all of them.

But the entire world is not Linux.

> > 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;
> > ”
>
> that's new text in c++17 (and yet another incompatibility
> with c).

In general, the C++ standard adheres much more to implementation 
experience than the C standard.  This incompatibility is probably a 
defect in the C standard.

Thanks,
Florian