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

[Szabolcs Nagy <szabolcs dot nagy at arm dot com>]

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)

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)