This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [RFC] Propose fix for race conditions in pthread cancellation (bz#12683)
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: Torvald Riegel <triegel at redhat dot com>
- Cc: Adhemerval Zanella <azanella at linux dot vnet dot ibm dot com>, "GNU C. Library" <libc-alpha at sourceware dot org>, Rich Felker <dalias at aerifal dot cx>
- Date: Fri, 12 Sep 2014 17:33:13 +0000
- Subject: Re: [RFC] Propose fix for race conditions in pthread cancellation (bz#12683)
- Authentication-results: sourceware.org; auth=none
- References: <5410C70E dot 70207 at linux dot vnet dot ibm dot com> <1410533066 dot 4967 dot 96 dot camel at triegel dot csb>
On Fri, 12 Sep 2014, Torvald Riegel wrote:
> I believe we can still avoid sending the signal with the new scheme;
> what we'd have to do is let the code for cancellable syscalls mark
> (using atomic ops) whether it's currently executing or not (ie,
> fetch_and_set to true and fetch_and_set to previous value); then the
> pthread_cancel should see whether it needs to send a signal or not.
> That adds a bit more synchronization, but seems possible.
Would this be calling C functions that do those atomic operations (in
similar places to where there are currently calls to
__pthread_enable_asynccancel etc.)? That would seem better than embedding
the atomic operation code directly in the macros that generate .S syscall
stubs, at least for architectures where there are multiple variants for
how atomic operations are implemented depending on things such as the
architecture version.
--
Joseph S. Myers
joseph@codesourcery.com