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

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

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)