This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [RFC PATCH glibc] pthread_setspecific: Provide signal-safety across keys
----- 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.
>
>> 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.
Hrm, if with GD there is indeed memory allocation performed within each
thread even after the initial explicit access done from the library
constructor, then I may indeed need to use IE instead, even though it's
a somewhat global resource.
But since lttng-ust can be dlopen'd, I understand that IE is not
appropriate neither.
It looks like there is no good solution there ?
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com