[PATCHv3] librt: Add posix_spawn support
dalias at aerifal.cx
Fri Apr 27 23:59:34 UTC 2012
On Fri, Apr 27, 2012 at 07:35:11PM -0400, Mike Frysinger wrote:
> On Friday 27 April 2012 18:33:08 Rich Felker wrote:
> > Why does librt still exist as a non-empty library? The only original
> > explanation I can think of is that, historically, it replaced some
> > functions in libc with versions that needed to behave specially for
> > compatibility with advanced realtime requirements.
> for some funcs, like mq_* and aio_* and lio_*, very few apps use them. so
> avoiding having them mapped in all the time is a good thing.
> librt also links against libpthread. i'd have to dig into the source/spec as
> to why glibc made that a requirement vs the normal libc forwarding pthread
That's a decent reason for keeping it separate (at least as long as
libpthread is separate), but then it should only contain the stuff
that depends on pthread, not clock_gettime, etc. And of course the
stuff that depends on pthread could just be merged into
> > But nowadays it's
> > just really annoying and harmful. With shared libraries, it adds bloat
> > and load time to every program which wants to use clock_gettime for
> > getting system time, which is every modern program.
> i'd side with the clock_* funcs being better in libc because they are getting
> used more and more as people transition away from gettimeofday()
And they are NOT part of any optional realtime option in POSIX;
they're a mandatory part of POSIX base.
> > Busybox even has a nasty workaround for this, making the clock_gettime
> > syscall directly to avoid librt.
> that's not really uClibc's fault. glibc does this too. and i find it hard to
> believe they couldn't just test -lrt ... after all, they do it with -lm
I believe the idea is to avoid pulling in librt.so because it makes
things a lot more bloated. (Several extra dirty pages for another .so,
plus the time to find/map/relocate it.)
> > Is anybody really opposed to just making librt.a empty, librt.so
> > nonexistent, and putting all the functions in libc.a/libc.so where
> > they belong?
> it would be really cool if we could split lesser used and standalone code into
> standalone shared libraries and libc.so was a simple linker script that pulled
> in all the other objects AS_NEEDED(...). but alas, that'd play havoc with
I don't understand how this is all that useful. If you have binaries
on your system that use standard functionality X, you'll have to have
it _somewhere_ anyway, and it might as well be in libc.so. If you're
worried about rare functions being spread out across lots of pages
that might also contain widely-used functions and increasing average
paged-in memory usage, it would be possible to add section attributes
to all the rare stuff to put it all in one contiguous part of libc.so
that would only be paged-in when stuff is actually using it.
More information about the uClibc