[Bug nptl/27880] Please provide a pthread pid accessor

["adhemerval.zanella at linaro dot org" <sourceware-bugzilla@sourceware.org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=27880

--- Comment #10 from Adhemerval Zanella <adhemerval.zanella at linaro dot org> ---
It seems that this is trickier than it seems, some issues we might considere
first:

  1. What should we do with detached threads? As for pthread_kill, issuing a
pthread_gettid_np might use an invalid handler (since the pthread_t identifier
might be reused).  This only solution I have is to define it as undefined
behavior, this is not great but to proper support it would incur to keep
tracking or all possible pthread_t identifiers (we already keep the glibc
provided stacks, dl_stack_cache, so it would be a matter to include the user
provided one in the list as special entries).

  2. I think that once we provide this API, developers will start to use o
query if a thread is alive and I am not sure if this is really the proper API
for this. This is the same issue as 1.

  3. How do we handle the concurrent access between pthread_join and
pthread_gettid_np? Once a pthread_join is issued, the pthread_t identifier
might be reused and accessing it should be invalid. pthread_join first
synchronizes using 'joinid' to avoid concurrent pthread_join and then wait the
kernel signal on 'tid' that the thread has finished.  The 'pthread_gettid_np'
naive check would just do a atomic load on tid, however it might read a
transient value between pthread_join 'joinid' setup and the futex wait.  I am
not sure how to handle it correctly.

Also, MacOSX signature is:

  int pthread_gettid_np (pthread_t thread, uint64_t *thread_id)

And it returns the current thread identification if THREAD is NULL, returns
ESRCH for invalid handle (the 1. and 2. issue below), and also consults the
kernel if the identifier can no be obtained.

I think for possible glibc symbols we should use a pid_t instead, the NULL
special arguments is also tricky because if by POSIX pthread_t might be NULL
(this is an implementation detail), for ESRCH we can our
INVALID_NOT_TERMINATED_TD_P (which not the best solution, but it the current
pratice).

-- 
You are receiving this mail because:
You are on the CC list for the bug.