This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [RFC PATCH glibc] pthread_setspecific: Provide signal-safety across keys
- From: Mathieu Desnoyers <mathieu dot desnoyers at efficios dot com>
- To: Joseph Myers <joseph at codesourcery dot com>
- Cc: Carlos O'Donell <carlos at redhat dot com>, Ben Maurer <bmaurer at fb dot com>, libc-alpha <libc-alpha at sourceware dot org>
- Date: Tue, 17 Oct 2017 22:27:17 +0000 (UTC)
- Subject: Re: [RFC PATCH glibc] pthread_setspecific: Provide signal-safety across keys
- Authentication-results: sourceware.org; auth=none
- References: <20171017212919.741-1-mathieu.desnoyers@efficios.com> <alpine.DEB.2.20.1710172153410.16511@digraph.polyomino.org.uk>
----- On Oct 17, 2017, at 5:55 PM, Joseph Myers joseph@codesourcery.com wrote:
> On Tue, 17 Oct 2017, Mathieu Desnoyers wrote:
>
>> The intent here is to provide signal-safety against callers to
>> pthread_{get/set}specific that work on different pthread keys,
>> without hurting performance of the normal use-cases that do not
>> care about signal-safety.
>
> If we wish to provide particular safety guarantees beyond whatever is
> required by POSIX, I think they should be documented in the glibc manual
> as a GNU extension.
Good point! I'm narrowing it down to this text:
manual/threads.texi
@deftypefun int pthread_setspecific (pthread_key_t @var{key}, const void *@var{value})
@standards{POSIX, pthread.h}
@safety{@prelim{}@mtsafe{}@asunsafe{@asucorrupt{} @ascuheap{}}@acunsafe{@acucorrupt{} @acsmem{}}}
@c pthread_setspecific @asucorrupt @ascuheap @acucorrupt @acsmem
@c a level2 block may be allocated by a signal handler after
@c another call already made a decision to allocate it, thus losing
@c the allocated value. the seq number is updated before the
@c value, which might cause an earlier-generation value to seem
@c current if setspecific is cancelled or interrupted by a signal
@c KEY_UNUSED ok
@c calloc dup @ascuheap @acsmem
Associate the thread-specific @var{value} with @var{key} in the calling thread.
@end deftypefun
We'd need to edit the part about level2 block and allocation.
The part about seq number should stay there. It's the part that states
non-async-signal-safety across concurrent uses of pthread_setspecific
for a given key.
Would this edited version work ? I'm not sure I grasp the full meaning
of @acsmem there.
@deftypefun int pthread_setspecific (pthread_key_t @var{key}, const void *@var{value})
@standards{POSIX, pthread.h}
@safety{@prelim{}@mtsafe{}@asunsafe{@asucorrupt{}}@acunsafe{@acucorrupt{} @acsmem{}}}
@c pthread_setspecific @asucorrupt @acucorrupt @acsmem
@c the seq number is updated before the value, which might cause
@c an earlier-generation value to seem current if setspecific is
@c cancelled or interrupted by a signal
@c KEY_UNUSED ok
@c dup @acsmem
Associate the thread-specific @var{value} with @var{key} in the calling thread.
@end deftypefun
Thanks,
Mathieu
>
> --
> Joseph S. Myers
> joseph@codesourcery.com
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com