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 8:03 AM, Szabolcs Nagy szabolcs.nagy@arm.com wrote:

> On 19/10/17 11:37, Mathieu Desnoyers wrote:
>> ----- On Oct 19, 2017, at 4:55 AM, Szabolcs Nagy szabolcs.nagy@arm.com wrote:
>>> 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 ?
>> 
> 
> well the idea was that you use tls access in signal handler
> and setup a tsd dtor in non-signal handler.
> (at tls access you can check some flag to see if the tsd
> for the thread is initialized or destructed)
> but this assumes you can make calls in the thread outside
> of a signal handler.

Unfortuntately, I need to setup the tsd dtor from the
signal handler.

> 
>> 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() ?
> 
> pthread_setspecific has well defined behaviour in dtors
> so EPERM is not ok.
> 
> but i dont think _np api for this is appropriate either.

So far the _np API is the less unappealing solution I have
found to solve the problem at hand. Do you have alternative
solutions to propose ?

Thanks,

Mathieu

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