This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug nptl/14304] New: Provide some parts of librt in libc as well
- From: "ajax at redhat dot com" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sources dot redhat dot com
- Date: Wed, 27 Jun 2012 14:59:55 +0000
- Subject: [Bug nptl/14304] New: Provide some parts of librt in libc as well
- Auto-submitted: auto-generated
http://sourceware.org/bugzilla/show_bug.cgi?id=14304
Bug #: 14304
Summary: Provide some parts of librt in libc as well
Product: glibc
Version: 2.13
Status: NEW
Severity: enhancement
Priority: P2
Component: nptl
AssignedTo: unassigned@sourceware.org
ReportedBy: ajax@redhat.com
CC: drepper.fsp@gmail.com
Classification: Unclassified
librt links against libpthread, mostly because aio_* are implemented in threads
instead of in the kernel AFAICT. This is unfortunate, because many libraries
would like to use (for example) clock_gettime, but doing so pulls in pthreads.
Now you have no choice but to hit the more expensive thread-safe paths, because
your library can't know whether multiple threads actually exist, only whether
the pthread symbols are non-zero.
The complementary problem also exists for applications that are unthreaded: if
they link against librt, pthread symbols will be non-zero, and any thread-safe
library beneath that app now has to behave thread-safely.
This is especially comic when reading the clock_gettime implementation, which
goes out of its way to work correctly regardless of whether
__pthread_clock_gettime is available.
Ideally it would be possible to provide most of these symbols from libc
directly (presumably versioned so the app requires a sufficiently new libc).
--
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.