[PATCH 6/6] nptl: Make pthread_{clock, timed}join{_np} act on all cancellation (BZ 33717)

Adhemerval Zanella Netto adhemerval.zanella@linaro.org
Thu Dec 18 18:16:09 GMT 2025



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?


More information about the Libc-alpha mailing list