This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [RFC PATCH glibc v2] pthread_setspecific: Provide signal-safety across keys
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.
> 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.