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

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

[Trevor Gross]

Hello,

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?

I could submit a patch, but require instruction on where this should live.

Thanks,
Trevor Gross

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

[Carlos O'Donell]

On 1/11/24 01:10, Trevor Gross via Libc-help wrote:
> 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?
> 
> I could submit a patch, but require instruction on where this should live.

This is much more complicated than it seems at first :-)

Please read through:
Bug 27880 - Please provide a pthread pid accessor
https://sourceware.org/bugzilla/show_bug.cgi?id=27880

Discussion here:
https://inbox.sourceware.org/libc-alpha/6d79a213-0df2-be8e-3596-e010f366a34f@linaro.org/

I don't recommend this as a "first contribution" kind of patch.

Are you looking to start with libc development?

Are you looking for an initial project to work on?

-- 
Cheers,
Carlos.

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

[Trevor Gross]

On Thu, Jan 11, 2024 at 1:23 PM Carlos O'Donell <carlos@redhat.com> wrote:
>
> On 1/11/24 01:10, Trevor Gross via Libc-help wrote:
> > 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?
> >
> > I could submit a patch, but require instruction on where this should live.

I appreciate the thorough response,

> This is much more complicated than it seems at first :-)
>
> Please read through:
> Bug 27880 - Please provide a pthread pid accessor
> https://sourceware.org/bugzilla/show_bug.cgi?id=27880
>
> Discussion here:
> https://inbox.sourceware.org/libc-alpha/6d79a213-0df2-be8e-3596-e010f366a34f@linaro.org/

Whoops, I didn't come across these in my search. Actually did not at
all come across pthread_getthreadid_np that is mentioned there, only
the similarly named pthread_gettid_np. Thanks for the links.

> I don't recommend this as a "first contribution" kind of patch.
>
> Are you looking to start with libc development?
>
> Are you looking for an initial project to work on?
>
> --
> Cheers,
> Carlos.
>

This was sort of a need-based suggestion that I am still interested
enough in looking into if there is a reasonable path forward. We were
discussing how to expose the OS TID, it was pointed out that this is
indirectly available via pthread_getcpuclockid ([1], [2]) but not
directly.

But indeed, it seems more complicated than originally thought :) I
will follow up in Florian's response.

- Trevor

[1]: https://github.com/bminor/glibc/blob/520b1df08de68a3de328b65a25b86300a7ddf512/nptl/pthread_getcpuclockid.c#L38
[2]: https://github.com/bminor/glibc/blob/520b1df08de68a3de328b65a25b86300a7ddf512/sysdeps/unix/sysv/linux/kernel-posix-cpu-timers.h#L23-L33

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

[Florian Weimer]

* 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

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

[Trevor Gross]

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])

- 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

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

[Adhemerval Zanella Netto]

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

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

[Florian Weimer]

* Adhemerval Zanella Netto:

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

I think this point is largely moot because we already provide this
information through pthread_getcpuclockid.  Applications can call this
function and reverse the encoding to get the TID.  We might as well make
this explicit, so that it's clearer that the application is asking for
the TID.

Thanks,
Florian