Mail Archives: cygwin/2005/06/12/22:47:44
> 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()?
>
Fork() also has to dup any and all handles/descriptors/etc, which takes all
kinds of time.
> 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()?
Something like this is on my "Master Plan Of Things I'll Probably Never Get
Around To". I can't for the life of me figure out why anybody ever thought
that the entire fork() concept was a good idea, indeed how they ever even
thought it up ("Oh my, wouldn't it be nice if I could magically duplicate
the entire state of my app in a new process, even though there has never
been a reason to do so?"), so my life's goal is to eliminate fork() entirely
from computer science. First step would be a shell that never forks.
--
Gary R. Van Sickle
--
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/
- Raw text -