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

["carlos at redhat dot com" <sourceware-bugzilla at sourceware dot org>]

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

--- Comment #26 from Carlos O'Donell <carlos at redhat dot com> ---
(In reply to Rich Felker from comment #23)
> 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.

The tid as we call it in userspace is actually a kernel pid. I don't know if we
want to talk about it at this level, but it is what it is, and many interfaces
that take a pid will also accept a tid because they are the same thing. In
practice the pid or tid are just identifiers of the kernel task that you are
trying to manipulate. All that I am looking for is a consistent use of
terminology at a particular level of abstraction. If we decide that "gettid"
returns a "Thread id" then that IMO can only be used with interfaces that are
documented as accepting a "thread id." I wish there to be no ambiguitiy between
pid and tid and pthread_t, and lines should be drawn between them.

Does that make sense?

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