Christopher Faylor wrote: > Recently, after too many hours hacking at vfork corner cases, I came to > the conclusion that getting vfork working correctly was too difficult > so, I turned off vfork in cygwin and asked Corinna to modify ash to use > /bin/sh again.
I assume that should read "modify ash to use fork() again." Can I just ask a basic question here? So if both ash and bash are using the same method of execution (fork), is the reason for bash's slowness due to it just being a larger program with more pages to copy during a fork()? And a related question: Would it make more sense to compile ash with all its builtins enabled, rather than switching to bash? It seems from the benchmarks that bash loses in speed due to its large size, but wins a lot back by having builtins that it can use for many features. If ash+builtins is still smaller than bash, wouldn't it solve both problems? (Of course if configure scripts choose bash automatically if present, then that sort of throws a wrench in that logic.) Final question: It seems to me that most of what a shell does for most common things is essentially "fork(); ... exec(); ... wait();". I'm sure there's an obvious reason why the following is not feasible, but would it be possible to special case this in the shell to use something that maps closer to the win32 api like spawn() so as to avoid having to fork()? Brian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
