This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]