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

[Carlos O'Donell <carlos at redhat dot com>]

On 10/17/2017 04:19 PM, Mathieu Desnoyers wrote:
> ----- On Oct 17, 2017, at 6:09 PM, Carlos O'Donell carlos@redhat.com wrote:
> 
>> On 10/17/2017 03:09 PM, Mathieu Desnoyers wrote:
>>> The __thread variable sits in a library shared object, so it's not
>>> possible to use the initial-exec model. 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.
>>
>> You *can* use IE model, but doing so *might* cause your library not to
>> load if we run out of static TLS space (some amount is reserved by the
>> static linker for loading such libraries that use IE model TLS).
>> The static TLS space is therefore something like a distro-wide global
>> resources :-)
>>
>> However, we don't recommend IE model if you can get away with the
>> performance of GD model and can manage to touch the variable early
>> before it might be used in a signal handler.
> 
> Touching it from a constructor only does it from the "main" thread
> perspective. Is there a need to touch it outside of a signal handler
> in every thread ?

Yes, you must touch the TLS variable in every new thread *outside*
of the signal handler, since each access in each new thread is
required to force the deferred allocation to be carried out.

I apologize for my earlier statement, I thought perhaps this was
just one thread of execution.

-- 
Cheers,
Carlos.