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

[Florian Weimer]

* Mathieu Desnoyers:

>> Then you really need to switch to real thread-local variables with the
>> intial-exec model, possibly with indirection through a thread-local
>> pointer variable and on-demand allocation using mmap in case you do
>> not want to have these allocations in every thread.
>
> Actually, liburcu-bp, which is the library actually using
> pthread_setspecific, does use a TLS pointer to a mmap'd region.
>
> The __thread variable sits in a library shared object, so it's not
> possible to use the initial-exec model.

glibc supports this, and there shouldn't be any issues if the library
is loaded into the initial process image (LD_PRELOAD or DT_NEEDED
reference).  dlopen can be problematic, though.  With current
upstream, additional initial-exec TLS variables do not impact later
dlopen.  (This was not always true.)

> I work around this by touching
> the object once in a library constructor before other threads are
> launched. AFAIU, this takes care of performing the TLS lazy fixup.

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.

But I have to admit that TLS access in signal handlers can be very
useful and is often the only way to implement certain things without
introducing a full managed runtime.