[Bug libc/6399] gettid() should have a wrapper

["mtk.manpages at gmail dot com" <sourceware-bugzilla at sourceware dot org>]

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

--- Comment #27 from Michael Kerrisk <mtk.manpages at gmail dot com> ---
(In reply to Nicholas Miell from comment #25)
> Should gettid() actually be exposed to userspace? My suggestion in bug 14300
> was the introduction of a pid_t "pthread_gettid_np(pthread_t *thr)" (which,
> naturally, could take pthread_self() as an argument).
> 
> Leaving gettid() hidden and only exposing the pthread function would act as
> an implicit hint that you really should be using the pthread functions where
> possible.
> 
> As such, acknowledging that the following functions take tids would be a
> mistake:
> 
> sched_getaffinity()
> sched_setaffinity()
> sched_getparam() 
> sched_setparam()
> sched_getscheduler()
> sched_setscheduler()
> 
> because the following functions already exist:
> 
> pthread_getaffinity_np() pthread_attr_getaffinity_np()
> pthread_setaffinity_np() pthread_attr_setaffinity_np()
> pthread_getschedparam() pthread_attr_getschedparam()
> pthread_setschedparam() pthread_attr_setschedparam()
> pthread_attr_getschedpolicy()
> pthread_attr_setschedpolicy()
> 
> And ideally the other functions like fcntl() or timer_create() would get
> small wrappers that that transparently convert a pthread_t to a tid before
> invoking the system call.

This makes no sense. System calls and the pthreads API are not the same; just
as kernel TIDs and Pthreads IDs are not the same. There are legitimate uses of
the system calls in applications that want nothing to do with Pthreads.  It
happens that there is a one-to-one correspondence between kernel TIDs and
Pthreads IDs, but that is an side effect of the NPTL implemntation. Any attempt
to force the two IDs to be conflated in the API would be a mistake.

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