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


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.


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