Re: [PATCH] nptl: Remove cancellation checks from sem_{timed}wait (BZ #23006)

[Florian Weimer <fweimer at redhat dot com>]

* Adhemerval Zanella:

> On 24/06/2019 14:17, Florian Weimer wrote:
>> * Adhemerval Zanella:
>> 
>>> The Austin group has decided that sem_wait and sem_timedwait do not need to
>>> be cancellation points.  This patch removes the cancellation checks in order
>>> to improve performance.
>>>
>>> As for comment #2 in BZ#23006, the old implementation which explicit check
>>> for cancellation is moved to a compat symbol.
>> 
>> The code nptl/sem_waitcommon.c still acts on a cancellation request, I
>> think.  The only change is that if we do not wait at all, we do not act
>> on the cancellation.  I don't think this matches the POSIX semantics,
>> where cancellation points are either there or not, and do not depend on
>> function implementation details.
>
> My understanding is defect #1076 is to make it more clear when exactly the
> 'may' cancellable entrypoints should act upon cancellation request, more
> specifically that cancellation should be used as a mechanism for preventing 
> indefinite blocking.
>
> Also, imho this specification does not clash from the 'Thread Cancellation 
> Overview' [1], which states that:
>
> For functions in the "may occur" list, a cancellation check may be performed
> on some calls but not others; i.e., whether or not a cancellation point occurs 
> when one of these functions is being executed can depend on current
> conditions."

My impression is that doesn't mean that the behavior is random (although
the wording allows for that).  It's dependent on how things have been
configured, and not on which threads wins a race during the call.

Any cancellation model which makes functions a cancellation points only
if they block has this problem.  It also means that future optimizations
(in glibc, the kernel, or the silicon) could effectively remove
cancellation points.  I don't think this is desirable.

Thanks,
Florian