[PATCH 07/11] nptl: Remove CANCELING_BITMASK

[Adhemerval Zanella]

On 15/06/2021 19:07, Florian Weimer wrote:
> * Adhemerval Zanella via Libc-alpha:
> 
>> The CANCELING_BITMASK is used as an optimization to avoid sending
>> the signal when pthread_cancel is called in a concurrent manner.
>>
>> This requires then to put both the cancellation state and type on
>> a shared state (cancelhandling), since 'pthread_cancel' checks
>> whether cancellation is enabled and asynchrnous to either cancel
>> itself of sending the signal.
>>
>> It also requires handle the CANCELING_BITMASK on
>> __pthread_disable_asynccancel, however this is incurs in the same
>> issues described on BZ#12683: the cancellation is acting even *after*
>> the syscalls returns with user visible side-effects.
>>
>> This patch removes this optimization and simplifies the pthread
>> cancellation implementation: pthread_cancel now first check if
>> cancellation is already pending and if not always send a signal
>> if the target is not itself.  The SIGCANCEL handler is also simpified
>> since there is not need to setup a CAS loop.
>>
>> It also alows to move both the cancellation state and mode out of
>> 'cancelhadling' (it is done in subsequent patches).
> 
> It looks like this causes sporadic failures in nptl/tst-sem16 because
> sem_wait fails with EINTR, revealing that cancellation is implemented
> using a signal (something that must not be visible according to POSIX).
> 
> This was not a problem before because pthread_cancel sent the signal
> only when asynchronous cancellation was enabled.
> 
> We either have to revert this, or push forward with the transition so
> that we can install the SIGCANCEL handler with SA_RESTART.

Indeed now that SIGCANCEL is always sent by pthread_cancel we must
install the signal handle with SA_RESTART, the signal handle will
either act on cancellation or it should be not visible by the 
application.

I don't think there is a need to revert this change, running nptl/tst-sem16
with SA_RESTART I don't see the regression anymore with multiple thousands
runs.