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

[enh]

On Tue, Mar 11, 2025 at 2:13 PM Florian Weimer <fweimer@redhat.com> 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.

yeah, i have quite mixed feelings about bionic's checking, and excuse
it mostly in the same way as Java's ConcurrentModificationExceptions
--- no, you can't rely on them, but, yes, they can help you (and
perhaps more importantly: others trying to debug your terrible code)
realize when you've lost track of your threads.

in particular, while i feel like "i caught you up to mischief,
congratulations on the abort() with a diagnostic explaining what you
did wrong" is defensible, quietly returning failure would be a
disaster. not nearly enough people check for failure, and _especially
in code like this_ half the people who do are just writing inherently
broken TOCTOU bugs for tids/pthread_ts.

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

sgtm. in particular, i like that you clearly call this out as
undefined behavior in the docs --- i've spent far too much time
getting various docs fixed to not mislead n00bs into thinking they can
use functions like this as thread-validity/existence tests.

> Thanks,
> Florian
>