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

[Szabolcs Nagy <szabolcs dot nagy at arm dot com>]

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)

and i think shared libraries are unimplementable for
c++ already (ctors can execute arbitrary code during
dlopen and can make it crash and there are odr issues
with vague linkage vs RTLD_LOCAL), so general dynamic
tls should not come up in a strictly conforming c++
program, so that's not a good reason to drop as-safety.

> 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).