[PATCHv3] librt: Add posix_spawn support

[Mike Frysinger]

On Saturday 28 April 2012 00:26:02 Rich Felker wrote:
> On Fri, Apr 27, 2012 at 11:57:38PM -0400, Mike Frysinger wrote:
> > On Friday 27 April 2012 19:59:34 Rich Felker wrote:
> > > On Fri, Apr 27, 2012 at 07:35:11PM -0400, Mike Frysinger wrote:
> > > > On Friday 27 April 2012 18:33:08 Rich Felker wrote:
> > > > > 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.
> > 
> > afaik, POSIX doesn't cover library layout in any way.  there is nothing
> > requiring us to stick all mandatory interfaces into -lc.  after all, much
> > of the math support falls into this category yet lives in -lm.
> 
> Actually, to some extent it does. See the documentation for the c99
> command:
> 
> http://pubs.opengroup.org/onlinepubs/9699919799/utilities/c99.html
> 
> POSIX allows certain -l options (which need not exist as a physical
> library file in the filesystem) to be required for using certain
> features; a conformant application (i.e. build script) must use them,
> but the implementation is not required to hide the symbols from you if
> you don't include them, and in fact it's perfectly conformant for them
> all to be ignored (i.e. everything available in the default
> library/libraries).

thanks.  that page pretty clearly explains why -lrt exists in the first place, 
and why glibc places all the symbols that it does in there.

> > > > 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 ABI/SONAMEs.
> > > 
> > > 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.
> > 
> > not everyone have virtual memory :p.  ignoring that, larger single
> > libraries means more reloc processing at init, and more string space to
> > search when resolving symbols.
> 
> I would suspect on a system without virtual memory, you'd decide to
> completely omit certain functionality from uClibc at config/build
> time if you don't need it for any of your bins. If you do need it for
> some of your bins, overall memory usage will almost surely be lower by
> having it in a common .so file rather than having another .so loaded
> in memory.

fragmentation is a much bigger problem than total memory usage, so having 
smaller bits split apart vs a single large blob is almost always more 
desirable.

> As for reloc processing, that's essentially zero if you use visibility
> (or -Bsymbolic-functions, the big stick) to bind as much as possible
> at .so creation time.

there are more relocs than just bypasing the PLT (which uClibc does heavily 
via hidden_xxx())

> String space is possibly an argument against including too much

hashing should mitigate much of the look-up costs

> not sure. I'll grant that there may be *some* arguments against
> integrating it all into either libc.so or libpthread.so, but I think
> those arguments are looking pretty weak compared to the arguments FOR
> doing it.

the only things that may be merged into libpthread are pthread funcs and stuff 
that absolutely requires them (for the obvious useless overhead in single 
threaded processes scenario).  i'm guessing librt links against libpthread 
because of the async api.  without kernel support, userspace threads are the 
only recourse for implementing that stuff.  and at that point, i don't see any 
real advantage to merging the pthread-dependent funcs from -lrt into -
lpthread.  they're not widely used, and POSIX allows us to say you must use -
lrt if you want them.

clock_gettime can sometimes call __pthread_clock_gettime when HP timing 
support is enabled, but that can handle the normal libc-pthread-forwarding 
logic, so moving that to libc is fine.

that leaves timer_* stuff which doesn't need pthread and is small (like, less 
than 1k), so throwing in libc is fine.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.busybox.net/pipermail/uclibc/attachments/20120428/bf2eb9e0/attachment.asc>