[PATCH 1/3] Linux: Add the pthread_gettid_np function

[Adhemerval Zanella Netto]

On 11/03/25 15:13, Florian Weimer wrote:
> * Adhemerval Zanella Netto:
> 
>> On 11/03/25 11:15, Florian Weimer wrote:
>>> * Adhemerval Zanella Netto:
>>>
>>>> So the question is whether we implement something similar to bionic,
>>>> and take the dl_stack_cache_lock to check if the pthread_t is 
>>>> within dl_stack_cache/dl_stack_user.  This will make the implementation
>>>> no async-signal-safe, but at least it would remove the potential UB.
>>>> We don't do this for other pthread functions, like pthread_join, but
>>>> if the idea is to use pthread_gettid to query the pthread_t lifetime
>>>> it would make sense to follow bionic here.
>>>
>>> No, I'm not proposing this function for this purpose.  It's really there
>>> to better support the TID argumnt for sched_setattr and similar
>>> functions.  (See the third patch in the series for examples.)
>>>
>>> Otherwise we would have to add pthread analogues for all
>>> these, and that seems excessive.  Conceptually, these functions can only
>>> work with 1:1 thread model because we couldn't context-switch scheduler
>>> policies in an n:m model.
>>
>> The problem is bionic already set a precedent and I am not feeling
>> comfortable on providing a non-portable symbol with same name with
>> slight different semantic.  This might cause more confusion once it is
>> mode wildly used, specially because android is a Linux based system.
> 
> I didn't realize there was a __pthread_internal_find function (which
> walks the thread list under a lock) and a newer implementation of
> pthread_gettid_np.
> 
> But I don't think the external contract that Bionic provides is
> different from what my patch provides: with the current API level, it's
> not possible to use pthread_gettid_np to probe whether a thread is
> running.  Either __pthread_internal_find terminates the process, or the
> implementation of pthread_gettid_np crashes reading from the TCB (which
> happens outside the scoped lock).  There is a special case for a null
> argument, which results in just a warning, but you can't use that for
> probing, either.
> 
> We don't have the full error checking in the proposed implementation,
> but given that Bionic does not return on an error, I still think your
> interfaces are reasonably close, and we can reuse the function name.

The main difference is bionic will always abort on invalid pthread_t,
so it helps to catch potential UB of accessing a pthread_t with an
expired lifetime.  But I agree that we already don't this for other
interfaces, so I don't think it should a requirement for this as well.