Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Date: Sun, 12 Jun 2005 22:51:28 -0400
From: Christopher Faylor <cgf-no-personal-reply-please AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: Making /bin/sh == bash.  Has the time come?
Message-ID: <20050613025127.GB3739@trixie.casa.cgf.cx>
Reply-To: cygwin AT cygwin DOT com
References: <20050610150729 DOT GA13181 AT trixie DOT casa DOT cgf DOT cx> <42ACF184 DOT E58BC2A8 AT dessent DOT net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <42ACF184.E58BC2A8@dessent.net>
User-Agent: Mutt/1.5.8i

On Sun, Jun 12, 2005 at 07:37:56PM -0700, Brian Dessent wrote:
>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."

Yes.

>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()?

I think it's more than that.  I think bash does a lot more stuff.  It
deals with job control and has more sophisticated handling of functions
and variables.  So, I think that every invocation of a new process ends
up executing more code in bash itself.

>And a related question: Would it make more sense to compile ash with all
>its builtins enabled, rather than switching to bash?

That still leaves us with an "ash != bash" situation although it does
reduce the support burden for ash if we get rid of the localized
streamlining hacks.

I'm still inclined to say that we should go with bash, just for
compatibility, since the speed differences don't seem to be that
great.

>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.)

If ash had all of bash's builtins and handled everything just like bash
and it was smaller, then yes, it would be a big win.  However, if all of
that was true, then it seems like there is something seriously wrong
with bash.

>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()?

The vfork implementation was essentially just a wrapper around spawn().
As soon as you start to contemplate using spawn instead of fork/exec you
will probably run into all of the same issues that eventually drove me
away from vfork.  The biggest problem was keeping track of file
descriptors.  Getting tty file descriptors right was a pain and getting
close-on-exec file descriptors right was another pain.  Getting pids
and process groups handled corectly was more pain.

As I have had time to ruminate about this, I think I've come to the
conclusion that I just didn't design things very well, so maybe the time
is ripe for another vfork implementation.  Even more interesting might
be an implementation that intelligently tried to use vfork when fork was
called -- that would give every program the benefit of vfork without
recompiling.

OTOH, there is a native Windows version of bash out there somewhere, isn't
there?  Maybe getting things working without fork would not be that hard
given that as a template.

cgf

--
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/