On Tue, 31 Jul 2012 00:16:32 +0200 Roland Mainz wrote: > 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... :-) ) ... ;-) alas the only magic in this case is _real_vfork _______________________________________________ ast-developers mailing list ast-developers@research.att.com https://mailman.research.att.com/mailman/listinfo/ast-developers
