This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] nptl: Remove cancellation checks from sem_{timed}wait (BZ #23006)
* 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