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

[Florian Weimer]

* 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