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

[Florian Weimer <fw at deneb dot enyo dot de>]

* Mathieu Desnoyers:

> ----- On Oct 17, 2017, at 6:19 PM, Florian Weimer fw@deneb.enyo.de wrote:
>
>> * 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.)
>
> Unfortunately, it is allowed to dlopen() the lttng-ust tracer library
> as well.

The question is whether this is a common use case, or if it is
acceptable to have somewhat limited support for this (in the sense
that if you dlopen many different libraries which use initial-exec
TLS, you might see a failure eventually).