Mailing-List:	contact cygwin-developers-help AT cygwin DOT com; run by ezmlm
List-Subscribe:	<mailto:cygwin-developers-subscribe AT cygwin DOT com>
List-Archive:	<http://sources.redhat.com/ml/cygwin-developers/>
List-Post:	<mailto:cygwin-developers AT cygwin DOT com>
List-Help:	<mailto:cygwin-developers-help AT cygwin DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender:	cygwin-developers-owner AT cygwin DOT com
Delivered-To:	mailing list cygwin-developers AT cygwin DOT com
From:	"Gary R. Van Sickle" <g DOT r DOT vansickle AT worldnet DOT att DOT net>
To:	<cygwin-developers AT cygwin DOT com>
Subject:	RE: fork() idea
Date:	Tue, 29 Jan 2002 00:53:10 -0600
Message-ID:	<NCBBIHCHBLCMLBLOBONKOEMNCJAA.g.r.vansickle@worldnet.att.net>
MIME-Version:	1.0
X-Priority:	3 (Normal)
X-MSMail-Priority:	Normal
X-Mailer:	Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To:	<04ce01c1a72e$2c597940$0200a8c0@lifelesswks>
X-MimeOLE:	Produced By Microsoft MimeOLE V6.00.2600.0000
Importance:	Normal

What about avoiding fork() entirely?  I'm of course not talking about a general
solution, but take sh for example; would it be possible to write a shell that
simply never forks (or has it already been done)?  That alone would be a massive
win.  Seems that one could simply (he sez) maintain a state stack where each
time you see a "var=$(echo something | somethingelse)", instead of forking you'd
just push a new shell state on the stack, spawn the commands, do the piping and
other shell-things in the same process, pop the stack and Bob's yer uncle, no
fork overhead.

Or am I missing something fundamental?

--
Gary R. Van Sickle
Brewer.  Patriot.

- Raw text -