Re: AW: Specific Linux syscalls for glibc API

[Rich Felker <dalias at libc dot org>]

On Wed, Nov 18, 2015 at 04:32:49PM +0000, Szabolcs Nagy wrote:
> On 18/11/15 16:07, Szabolcs Nagy wrote:
> >On 18/11/15 12:57, Warlich, Christof wrote:
> >>On 11/17/2015 05:34 PM, Joseph Myers wrote
> >>>* gettid, pthread_gettid_np (bug 6399).
> >>
> >>I'm not sure w.r.t. the added value of a gettid wrapper though: Assuming the
> >>availability of pthread_gettid_np(), pthread_gettid_np(pthread_self()) would
> >>(apart from some locking to prevent thread termination in the meantime) just
> >>do what gettid() is supposed to do.
> >>
> >
> >i don't see why would you lock there.
> >(this api should be as-safe)
> >
> >pthread_gettid_np is problematic api because of the
> >issue Florian raised (tid is lost after a thread
> >exited but not yet joined and that should not be
> >visible to the caller, so this api is only possible
> >to implement if tid handling is redesigned).
> 
> ignore this
> 
> tid is not useful after the thread exited,
> so using a tid has to be synched with thread
> exit, so the user of the tid must know about
> the thread exit event, pthread_gettid_np does
> not expose anything it shouldn't.

Well, it's arguable that only gettid should exist, not
pthread_gettid_np, because using the tid of any thread other than
yourself requires synchronizing with that thread to ensure that it
does not exit before you use the tid.

However if it's common to have real-world situations where you already
have a guarantee that the target thread won't exit before other
threads expect it to, pthread_gettid_np could still be reasonable and
useful to have.

Rich