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

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

----- On Oct 19, 2017, at 4:55 AM, Szabolcs Nagy szabolcs.nagy@arm.com wrote:

> On 18/10/17 17:31, Mathieu Desnoyers wrote:
>> ----- On Oct 18, 2017, at 7:37 AM, Szabolcs Nagy szabolcs.nagy@arm.com wrote:
>>> dtors must not run with signals blocked (posix does not
>>> say that dtors may see changed signal mask)
>> 
>> Would it be more acceptable to have a "thread_exiting" flag,
>> and have pthread_{get,set}specific return NULL and EPERM
>> respectively when invoked from dtors and from signal handlers
>> nested over thread teardown ?
>> 
>>>
>>> i think it's the user's fault if there is async
>>> pthread_getspecific call while a thread is exiting.
>>> the user can block the signals before thread exit
>>> if that's the intended behaviour.
>> 
>> In the lttng-ust tracer use-case, I cannot change the application.
>> A simple library could be instrumented, and use lttng-ust for
>> tracing, without any change to the application. So unfortunately
>> the solution you are proposing does not work in my case.
>> 
> 
> instead of adding hacks to the libc and abusing the tsd apis,
> why not use tls? in c11 that is as-safe (unfortunately glibc
> does not implement this correctly, but e.g. in musl libc all
> tls accesses are as-safe so it can be done, with glibc you
> would have to use initial-exec tls, so it won't work with
> dlopen, but that's a glibc bug)

I indeed try to use TLS whenever possible. Unfortunately,
I also need to perform lazy thread registration (e.g. add
thread to a linked list for urcu-bp, or register to the kernel
new rseq system call), which needs to be paired with an
unregistration before the thread exits. I found that
pthread_key is a good match for that use-case. The main issue
is its non-signal-safety.

> 
> if you need dtors then the tsd apis can be used for that and
> you can block signals in your dtors before cleaning tls state.
> (this would be portable to any conforming libc implementation)

I'm not sure I understand your statement here. I need to set a
dtor from a signal handler, but AFAIU in the previous statement
you said tsd apis were not async signal safe. Perhaps I
mis-associate "tsd apis" to pthread_{get,set}specific and you
have something else in mind ?

By the way, rather than adding a new "EPERM" return code to
pthread_setspecific to handle the case where it is invoked
from a thread dtors (which would be non-posix and unexpected),
perhaps we should introduce a pthread_setspecific_np() ?

Thanks,

Mathieu

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