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

[Florian Weimer]

* 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.

Thanks,
Florian