This is the mail archive of the glibc-bugs@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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

--- Comment #32 from Gabriele Svelto <gabriele.svelto at gmail dot com> ---
(In reply to Nicholas Miell from comment #28)
> If the application isn't implementing their own threading library, then the
> application is using pthreads, which operates on pthread_t, not TIDs.

The issue here is that the pthread API doesn't support some IMHO basic
functionality that is available when manipulating TIDs directly. To give a
concrete example, on Linux you can't adjust the priority of a POSIX thread with
pthread_setschedparam()/pthread_setpriority() unless it's running on a
non-standard scheduler (i.e. anything but SCHED_OTHER). In practice this means
that on a regular system without special permissions you simply can't adjust
thread priorities relative to each other via the pthread interfaces.

However every process can increase its nice value without requiring special
permissions; so since a PID and a TID are the same thing we work around this
problem in Gecko by retrieving each thread TID with gettid() and then adjusting
their nice values via setpriority() (which accepts a PID).

While this is an ugly hack it works fine and offers a bit of functionality that
is currently not available via the pthread interfaces while being well
supported by the Linux kernel. This is unfortunate as we're basically keeping
around a non-POSIX code path in addition to a regular POSIX path using
pthread_setschedparam() which works fine on BSDs for example.

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]