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 #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.


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