Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
From: "Gary R. Van Sickle" <g DOT r DOT vansickle AT worldnet DOT att DOT net>
To: <cygwin AT cygwin DOT com>
Subject: RE: OT: possible project/research project
Date: Wed, 20 Mar 2002 21:25:03 -0600
Message-ID: <NCBBIHCHBLCMLBLOBONKEEAECMAA.g.r.vansickle@worldnet.att.net>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
In-Reply-To: <FC169E059D1A0442A04C40F86D9BA76062DF@itdomain003.itdomain.net.au>
Importance: Normal

> The issue at hand though, is twofold:
> 1) Minimise the changes needed to make a proxy for a program. I.e.
> imagine if GCC and cc1plus.exe lived in-process. That would remove 2Mb
> of disk IO for each compile. However the _only_ chance of getting such a
> program proxied would be a minimalistic, non-intrusive approach, or
> keeping a patched branch :[.
> 2) Make the context saving and restoring as low-overhead as possible.
> (if this is > spawn() + wait, there is no point).
>
> Rob

My thinking on this matter (and I've been cogitating about it for some time
actually) takes a slightly different tack.  My basic ideas for a "modernized sh"
are:

1.  Eliminate as much fork()ing as possible, ideally all of it.
2.  Get some concurrency going.

#1 is basically the same as what you propose, though I'm not sure I'm wild about
the DLL idea; if everything's a builtin, why not just statically link?

#2 I think could be a significant win even for Unix folk.  Basically I'm
thinking along the lines of a "pipelined shell", e.g.:

# Why should this...:
rm //a/bunch/of/files/out/on/a/super/slow/server/*
# ...block this:
gcc hello.c

Obviously you're never going to be able to take advatage of all
non-dependencies, but as a wise man once told me, "you can't win if you don't
enter".

--
Gary R. Van Sickle
Brewer.  Patriot.


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/