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)
Right... the idea was to use |posix_spawn()| to avoid such nasty issues and give more performance (assuming |posix_spawn()| is implemented as system call... it avoids the |(v)fork()|+|exec()| ([1]) overhead, e.g. first duplicating lots of resources of the parent process and then throw them away. |posix_spawn()| as system call avoids this by only doing the minimum neccesary stuff as requested by the caller... and not all possible things which are required for a full standard-conforming |fork()|). [1]=|vfork()|/|fork()| being obvious, however on large SMP+NUMA machines |exec()| wheights much more since on such machines each |exec()| makes crosscalls to all CPUs to tear down the address space, something which already hurts a lot on Sun's SF25k-class machines+large Niagara machines (e.g. T5440 with 256 hardware threads. Remeber that Sun had service calls (with very angry and impatient customers) where a plain sendmail script (or similar thing) was tearing-down a whole 2 Million Euro SF25k (Fujitsu SPARC64 is even a bit worse in this aspect and the >= 8-way AMD64 machines don't exactly do much better in this case (Olga may know more about the ARM side)) down to the knees just because it was doing a tight |fork()|+|exec()| loop. And this is not something which is going to be fixed soon (because it is 80% an hardware issue and 20% software) - AFAIK the only research into this issue was done by Sun ... and they are... gone (Oracle disbanded the research team because they don't like research which can't be monetarised in the next 5-10 years (and project "Infinity" went far beyond that)). ---- 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
