Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Delivered-To: mailing list cygwin@cygwin.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: 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" To: "Gary R. Van Sickle" , 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.r.vansickle@worldnet.att.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/