This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug libc/6399] gettid() should have a wrapper
- From: "bugdal at aerifal dot cx" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sourceware dot org
- Date: Fri, 10 Jan 2014 20:56:24 +0000
- Subject: [Bug libc/6399] gettid() should have a wrapper
- Auto-submitted: auto-generated
- References: <bug-6399-131 at http dot sourceware dot org/bugzilla/>
https://sourceware.org/bugzilla/show_bug.cgi?id=6399
--- Comment #23 from Rich Felker <bugdal at aerifal dot cx> ---
I'm unclear on what you mean by clarifying that it's not a thread id. Is this
just a matter of distinguishing it from pthread_t? Or are you hesitant to
establish a permanent one-to-one correlation between threads from the
application's perspective and threads from the kernel's perspective? The idea
of implementing POSIX threads with an M:N threading approach is dead and buried
as far as I can tell; it's largely incompatible with POSIX semantics for
scheduling and blocking syscalls, unless you add a huge userspace emulation
layer even uglier than what LinuxThreads was. This is not an implementation
flaw in glibc or Linux but a fundamental limitation.
I think it's perfectly reasonable to add gettid, documenting it as
Linux-specific, and documenting that each thread (in the POSIX or C11 sense)
has a corresponding kernelspace identifier, in the form of a 32-bit positive
signed integer, used for certain Linux-specific features. In addition, since
this identifier is guaranteed to be unique per thread, it may be used by
applications implementing their own synchronization mechanisms via atomics and
futex. (Note that pthread_t is not useful for this purpose, since it may be
64-bit, whereas futex only supports 32-bit values.)
--
You are receiving this mail because:
You are on the CC list for the bug.