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
Subject: RE: OT: possible project/research project
Date: Wed, 20 Mar 2002 18:14:01 +1100
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Message-ID: <FC169E059D1A0442A04C40F86D9BA76062DF@itdomain003.itdomain.net.au>
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
X-MS-Has-Attach: 
content-class: urn:content-classes:message
X-MS-TNEF-Correlator: 
From: "Robert Collins" <robert DOT collins AT itdomain DOT com DOT au>
To: "Gary R. Van Sickle" <g DOT r DOT vansickle AT worldnet DOT att DOT net>, <cygwin AT cygwin DOT com>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id g2K7FQQ04386



> -----Original Message-----
> From: Gary R. Van Sickle [mailto:g DOT r DOT vansickle AT worldnet DOT att DOT net] 
> Sent: Wednesday, March 20, 2002 1:52 PM

> 
> I don't see it that the source of the problem is the 
> implementation of fork/vfork; the way I see it the very 
> *concept* of forking makes little to no sense.  I've written 
> a lot of code, and not once have I thought to myself, "ok, 
> now what I want to do here is duplicate the current process 
> in almost exactly its current state."  Maybe it made more 
> sense back in the day, or maybe I'm missing something, but it 
> seems to me there's a lot more efficient ways to do 
> multithreading/multi"process"ing/IPC/etc (or better yet avoid 
> them altogether) these days.

Well, most high-performance systems use a combination of MT,MP and IPC.
Look at IIS for instance (not that I like MS :}). IIS uses in-process
filters to allow modularity and extensability, much like apache does -
now - with modules. (i.e. consider the php module vs the php cgi). In
such cases performance and scalability go up dramatically. However there
is a maintenance cost - it's harder to keep a system in good design the
more tightly coupled it is.

MT/MP and IPC will (IMO) allways have a place, because of the loose
coupling they allow. However COM & CORBA also allow loose coupling AND
in-process behaviour, so a happy can be found.

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

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