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 sources dot redhat dot com
- Date: Mon, 05 Nov 2012 20:56:55 +0000
- Subject: [Bug libc/6399] gettid() should have a wrapper
- Auto-submitted: auto-generated
- References: <bug-6399-131@http.sourceware.org/bugzilla/>
http://sourceware.org/bugzilla/show_bug.cgi?id=6399
Rich Felker <bugdal at aerifal dot cx> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |bugdal at aerifal dot cx
--- Comment #5 from Rich Felker <bugdal at aerifal dot cx> 2012-11-05 20:56:55 UTC ---
Michael, your argument about static linking is invalid; it is not the
application embedding the assumption, it's part of the implementation embedding
the assumption. Being static-linked, both lie in the same file.
With that said, I think there is at least _some_ merit to the idea of exposing
kernel TIDs to applications, since the time when thread implementations without
a one-to-one correspondence between kernel threads and userspace threads seemed
viable is long-past. (It is virtually impossible for such implementations to
meet all the requirements of POSIX regarding scheduling, signals, cancellation,
blocking syscalls, etc., and they have no benefits with regard to performance.)
Such an interface (gettid) should of course not be part of the general glibc
API, but if exposed, would be a linux-specific function, like numerous other
linux extensions, for use only with interfaces like SIGEV_THREAD_ID, fcntl,
etc., and should be clearly documented as non-portable.
--
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.