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: "carlos at redhat dot com" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sourceware dot org
- Date: Sat, 11 Jan 2014 03:03:18 +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 #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.