[RFC] Propose fix for race conditions in pthread cancellation (bz#12683)

[Joseph S. Myers]

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