[PATCH 6/6] nptl: Make pthread_{clock,timed}join{_np} act on all cancellation (BZ 33717)
Florian Weimer
fweimer@redhat.com
Thu Dec 18 18:23:45 GMT 2025
* Adhemerval Zanella Netto:
> On 15/12/25 08:22, Florian Weimer wrote:
>> * Adhemerval Zanella Netto:
>>
>>> On 12/12/25 16:40, Florian Weimer wrote:
>>>> * Adhemerval Zanella:
>>>>
>>>>> The pthread_join/pthread_timedjoin_np/pthread_clockjoin_np will not act
>>>>> on cancellation if 1. some other thread is already waiting on the 'joinid'
>>>>> or 2. If the thread has already exited.
>>>>
>>>> 1. is undefined, so only 2 is relevant.
>>>>
>>>>> diff --git a/nptl/pthread_join_common.c b/nptl/pthread_join_common.c
>>>>> index 6cdb710bc9..ddf10133c1 100644
>>>>> --- a/nptl/pthread_join_common.c
>>>>> +++ b/nptl/pthread_join_common.c
>>>>> @@ -28,6 +28,9 @@ __pthread_clockjoin_ex (pthread_t threadid, void **thread_return,
>>>>> const struct __timespec64 *abstime,
>>>>> bool cancel)
>>>>> {
>>>>> + if (cancel)
>>>>> + __pthread_testcancel ();
>>>>> +
>>>>> struct pthread *pd = (struct pthread *) threadid;
>>>>
>>>> Should pthread_tryjoin_np, pthread_clockjoin_np be a cancellation
>>>> points? For pthread_clockjoin_np yes, but it's more complicated for
>>>> pthread_tryjoin_np.
>>>
>>> The pthread_clockjoin_np is already a cancellation entrypoint and I
>>> think it makes sense to do so (as per POSIX below).
>>>
>>>>
>>>> Any thoughts on that? We could avoid making it a cancellation point
>>>> because pthread_tryjoin_np can never block. So applications that need
>>>> to act upon cancellation probably already call pthread_testcancel.
>>>
>>> POSIX rationale to specify a cancellation entrypoint is [1]:
>>>
>>> Typically, only those routines that may block or compute indefinitely
>>> need to include cancellation points.
>>>
>>> Currently pthread_tryjoin_np should not block: __pthread_clockjoin_ex
>>> will always be called when the thread is already terminated (pd->tid
>>> equal to 0).
>>>
>>> And since it is being marked as __THROW since its inception, I don't
>>> think making it a cancellation entrypoint will align with POSIX or
>>> improve things here.
>>>
>>> And I think to make is cancellation entrypoint would require a new
>>> symbol version.
>>>
>>> [1] https://pubs.opengroup.org/onlinepubs/9799919799/
>>
>> Fair enough, I agree.
>>
>> Thanks,
>> Florian
>>
>
> Right, are you ok with the patch as-is?
Yes, please.
Reviewed-by: Florian Weimer <fweimer@redhat.com>
Thanks,
Florian
More information about the Libc-alpha
mailing list