[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