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 12:55 PM, Szabolcs Nagy szabolcs.nagy@arm.com wrote:

> On 19/10/17 13:59, Mathieu Desnoyers wrote:
>> ----- On Oct 19, 2017, at 8:03 AM, Szabolcs Nagy szabolcs.nagy@arm.com wrote:
>>>> 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 ?
>> 
> 
> the original approach tried to make pthread_setspecific
> as-safe as an extension which has non-trivial requirement
> on thread exit as discussed:
> 
> thread exit retries the tsd dtors until all tsd values
> are NULL, if setspecific may run in a signal handler
> that means this loop should only stop if all tsd values
> are still NULL after signals are masked (and signals
> remain masked until the thread exits).
> 
> this way when your library is called you can always
> do the 'register thread' operation and then the dtor
> with 'unregister thread' operation will be run even
> if the call happened in a signal interrupting tsd dtors.
> (you may need to mask signals in your own dtor though)
> 
> currently the dtor retry loop only runs a fixed number
> of iterations (dtors of non-NULL tsd values after the
> last iteration are not run), but posix allows an infinite
> loop there, which would be appropriate for as-safe
> setspecific. (i don't know if that breaks anything)
> 
> your second approach exposes whether tsd dtors have
> started running and then you skip 'register thread'
> if it seems the thread is exiting. there are various
> ways to expose this information (return value of
> pthread_setspecific_np may not be the best one) and
> it's not clear if this is useful for others as well
> or just for this specific application (which does
> not seem to care about library calls that happen
> after the thread is exiting)

Good points! This brings me to a third approach that would
fit my use-case, and perhaps be more generic than the
pthread_setspecific_np approach. We could introduce a
new as-safe "query" function, e.g. pthread_exiting(),
which could be called by the application to conditionally
decide not to invoke pthread_setspecific() from dtors and
signal handlers nested over dtors. In applications like a
tracer, or liburcu-bp trying to register a thread, doing
that registration while in the thread dtors is pretty much
useless, so it could be simply skipped.

Thoughts ?

Thanks,

Mathieu

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