Re: RFC: A way to get a TID from a pthread_t handler

[Adhemerval Zanella Netto <adhemerval.zanella@linaro.org>]

On 12/01/24 04:55, Trevor Gross wrote:
> On Thu, Jan 11, 2024 at 4:32 PM Florian Weimer <fweimer@redhat.com> wrote:
>>
>> * Trevor Gross via Libc-help:
>>
>>> It seems like there isn't a good way to get the thread ID from a
>>> pthread_t. If you are within the thread then you can call gettid(),
>>> but there is no public API to get a spawned thread's TID after calling
>>> pthread_create().
>>>
>>> This value is stored in the pthread, so a new public function could
>>> just be a basic getter:
>>>
>>>     pid_t pthread_gettid(pthread_t threadid)
>>>     {
>>>       struct pthread *pd = (struct pthread *) threadid;
>>>       return pd->tid;
>>>     }
>>>
>>> Would an addition like this likely get accepted? Or is there anything
>>> overlooked about an easier way to recover the spawned thread's TID?
>>
>> We should probably make a copy of the TID inside pthread_create and
>> return that from pthread_gettid, instead of pd->tid that might be
>> cleared by the kernel upon thread exit.  This way, pthread_gettid
>> remains valid until pthread_join is called.
>>
>> Thanks,
>> Florian
>>
> 
> As in, store a second pid_t value within pthread? This sounds doable,
> I think that would sidestep a lot of the problems listed in [1]. Maybe
> it could also be used other places after a INVALID_TD_P check, such as
> at [2], to still return something somewhat valid if the check returns
> a false positive.
> 
> Adding Adhemerval based on the thread, did you ever prototype an
> implementation for this? (pthread_gettid_np, [1])

Not really, mainly because I am not fully convinced that returning the
TID is really a good idea.  It means that we will have two unique
identifiers for a pthread thread that might eventually get out of sync
(which would require us to add some support to return the correct value),
and it is API deviation that need some justification (since pthread was
defined as pthread_t being a opaque identifier).

So the question is which Linux support are you trying to expose by an
external call that can not be factored by a possible pthread extension
and if this interface does make sense.

> 
> - Trevor
> 
> [1]: https://inbox.sourceware.org/libc-alpha/6d79a213-0df2-be8e-3596-e010f366a34f@linaro.org/
> [2]: https://github.com/bminor/glibc/blob/520b1df08de68a3de328b65a25b86300a7ddf512/nptl/pthread_getcpuclockid.c#L38