On Tue, Jul 31, 2012 at 12:00 AM, Glenn Fowler <g...@research.att.com> wrote: > On Mon, 30 Jul 2012 22:46:08 +0200 Roland Mainz wrote: >> On Mon, Jul 30, 2012 at 10:23 PM, Tom Honermann <thonerm...@coverity.com> >> wrote: [snip] >> > Per the following email thread, I surmise that ksh's use of vfork() on >> > systems that support posix_spawn() is unintentional. It seems the glibc >> > posix_spawn() implementation had a defect that caused ksh to avoid using >> > it. >> > https://mailman.research.att.com/pipermail/ast-developers/2012q3/001495.html >> > (The glibc defect is described at >> > https://mailman.research.att.com/pipermail/ast-developers/2012q3/001601.html) > > the case of working for a certain class of intercept calls > isn't strictly a posixly-correct situation > > I'll do some timing tests to see how much #undef _real_vfork costs > if its negligible then it can become the default
Please make sure the shell has swallowed a few MB of data (e.g. $ x=$( < 'satanically_large_text_file.txt' ) #) before running the |vfork()| performance tests. >> See my email I split-off from this thread... > >> Glenn: Is it possible to somehow work around the half-broken glibc >> |posix_spawn()| behaviour (the fix is in newer glibc versions... but I >> assume the old version will still float around for the next 2-3 years >> and tries to hunt-down some innocent victims...) ? > > I don't know how to work around that behavior > to recap: the ksh "run this command" loop basically does > find the executable file > try spawnveg() > if spawnveg() fails with ENOEXEC then try it as a shell script > *in the current shell process* > if spawnveg() used the iffe-rejected posix_spawn() instead of getting > ENOEXEC posix_spawn() would call /bin/sh (or whatever undocumented shell it > calls) > causing the overhead of posix_spawn() on a completely separate and most likely > different sh than the caller without giving ksh a choice in the matter Well... I had a similar conclusion... but I hoped that you magically find a loophole, workaround or other solution somehow (e.g. the usual gsf magic... :-) ) ... ;-) ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.ma...@nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 3992797 (;O/ \/ \O;) _______________________________________________ ast-developers mailing list ast-developers@research.att.com https://mailman.research.att.com/mailman/listinfo/ast-developers
