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

[Mathieu Desnoyers <mathieu dot desnoyers at efficios dot com>]

----- On Oct 18, 2017, at 2:38 PM, carlos carlos@redhat.com wrote:

> On 10/18/2017 11:16 AM, Mathieu Desnoyers wrote:
>> ----- On Oct 18, 2017, at 1:40 PM, carlos carlos@redhat.com wrote:
>> 
>>> On 10/18/2017 09:21 AM, Mathieu Desnoyers wrote:
>>>> So let's assume dlopen failure is acceptable if there are too many
>>>> initial-exec TLS. Would it work today to fix signal handler tracing
>>>> by changing lttng-ust to use TLS_IE, or would it require changes to
>>>> glibc ?
>>>
>>> No changes to glibc are required. We already use TLS IE in glibc
>>> specifically to fix this issue. Also libGL also uses TLS IE in
>>> the distro for performance reasons, so we get testing there.
>>>
>>> How much TLS data do you have? With libGL it's just a few words,
>>> and there is lots of spare space in the static TLS space for
>>> that.
>> 
>> For liburcu-bp, used by lttng-ust, a single pointer:
>> 
>> DEFINE_URCU_TLS(struct rcu_reader *, rcu_reader);
>> 
>> I make sure to do place the bulk of data into mmap'd memory.
>> So, very little TLS space is required.
> 
> Perfect. Just like libGL then, which just has two pointers.
> 
> The probability of your library not loading is going to be
> vanishingly small, so I think you can switch to TLS IE without
> a problem.

I'm trying to figure out the right TLS model for each liburcu
libraries. Given that it means a major soname bump, I prefer to
get it right from the get go.

For TLS meant to be touched by a signal handler at first use
in a thread, the hard requirement seems to be TLS initial-exec.
This takes care of urcu-bp, the call-rcu, and rcu-defer TLS.

I have other liburcu flavors where the application is required to
explicitly register the TLS data structure at thread start. This
lifts the "hard" requirement on making the first use signal-handler
safe, given that I can mandate the registration to be performed
outside of signal handler.

The largest data structure I have is 64 bytes. Is it still
acceptable for the IE model ?

I understand that there is a performance benefit in using
the initial-exec model over the global-dynamic. Given liburcu
tends to be used on fast-paths, should I simply move all
liburcu TLS variables to the IE model ?

Thanks,

Mathieu



> 
> --
> Cheers,
> Carlos.

-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com