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)
- From: Florian Weimer <fweimer at redhat dot com>
- To: Adhemerval Zanella <adhemerval dot zanella at linaro dot org>
- Cc: libc-alpha at sourceware dot org
- Date: Thu, 04 Jul 2019 16:19:57 +0200
- Subject: Re: [PATCH] nptl: Remove cancellation checks from sem_{timed}wait (BZ #23006)
- References: <20190624170216.26723-1-adhemerval.zanella@linaro.org> <877e9a9a38.fsf@oldenburg2.str.redhat.com> <a8987851-1412-ed5a-bacb-84bfe0ddf2a4@linaro.org> <8736jx506o.fsf@oldenburg2.str.redhat.com> <c22e8875-9324-644b-7608-e1a9f96887d7@linaro.org> <87sgrx3ks1.fsf@oldenburg2.str.redhat.com> <27e63669-4e22-73a0-5025-45eaed7cb444@linaro.org> <87lfxp23da.fsf@oldenburg2.str.redhat.com> <a9c62e63-9b68-8b6b-ebb1-2c93219c38a4@linaro.org> <4b7bfbf5-d6a6-771d-d14f-4893cb3c9dd8@linaro.org> <87zhlvm0pi.fsf@oldenburg2.str.redhat.com> <ea08ee54-c50b-1a95-b7bc-e4aca766f279@linaro.org>
* Adhemerval Zanella:
> On 03/07/2019 15:28, Florian Weimer wrote:
>> * Adhemerval Zanella:
>>
>>> On 25/06/2019 11:29, Adhemerval Zanella wrote:
>>>>
>>>>
>>>> On 25/06/2019 10:36, Florian Weimer wrote:
>>>>> * Adhemerval Zanella:
>>>>>
>>>>>> In any case, do you think we should make sem_{timed}wait not a cancellation
>>>>>> entrypoint for 2.30? I can rework the patch if it is the case.
>>>>>
>>>>> Do we have any other form of blocking synchronization that is
>>>>> cancellable? If not, a cancellable semaphore wait operation would make
>>>>> sense. But then we should perform the cancellation check on the fast
>>>>> path, too.
>>>>
>>>> pthread_cond_wait, pthread_cond_timedwait, and pthread_join as well the
>>>> gnu extension pthread_timedjoin_np and pthread_cond_clockwait (not yet
>>>> upstream). Depending of you definition of synchronization, you can also
>>>> include sigtimedwait, sigwait, sigwaitinfo, wait, waitid, and waitpid.
>>>>
>>>> We explicit does not support cancellation for pthread_rwlock_rdlock,
>>>> pthread_rwlock_timedrdlock, pthread_rwlock_timedwrlock, and
>>>> pthread_rwlock_wrlock. I tend to see that pthread_rwlock_* are similar
>>>> to pthread_mutex and the rationale layout on 'Thread Cancellation
>>>> Overview' also applies.
>>>>
>>>> So at least we have synchronization functions that explicit does not
>>>> act for cancellation, we might extend it to sem_{timed}wait now that
>>>> they are also listed on 'shall'.
>>>>
>>>> However, I still think this does not really follow along with the
>>>> rationale exposed on the very issue that triggered it [1], which aimed
>>>> imho to just remove the requirement of check for cancellation on fast
>>>> path only.
>>>>
>>>> [1] http://austingroupbugs.net/view.php?id=1076#c3938
>>>>
>>>
>>> Florian, how should we proceed regarding it? Should we just move
>>> sem_{timed}wait out of the cancellable entrypoints or act uppon just
>>> for the potentially blocked case? For latter do you still think we
>>> should keep a compat symbol for early check?
>>
>> Ugh, to be honest, I don't think any code change is required here.
>
> By 'here' do you mean the patch or current implementation? I still think
> we can use the Austin clarification to optimize the sem_{timed}wait
> and remove the early checks for the non-blocked case. And I also don't
> think it is worth to add a compatibility check for this specific
> semantic.
I think the optimization is invalid, for the reasons I outlined earlier.
Thanks,
Florian