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
Date: Wed, 20 Mar 2002 11:46:59 -0500
From: Christopher Faylor <cygwin AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: OT: possible project/research project
Message-ID: <20020320164659.GI2762@redhat.com>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
References: <FC169E059D1A0442A04C40F86D9BA7600AFDC5 AT itdomain003 DOT itdomain DOT net DOT au>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <FC169E059D1A0442A04C40F86D9BA7600AFDC5@itdomain003.itdomain.net.au>
User-Agent: Mutt/1.3.23.1i

On Wed, Mar 20, 2002 at 06:04:44PM +1100, Robert Collins wrote:
>In fact cgf has had a copy-on-write fork() for cygwin in alpha-quality
>IIRC. I'd love to do some perf tests with that, and in fact on my todo
>list is cygwin profiling. Time however, is the killer.

This keeps coming up.  Maybe it should be added to the FAQ.

The copy-on-write semantics available in the Windows API are not
adequate for fork.  copy-on-write doesn't work right on 9x/Me and, even
on NT, there is no way, AFAICT, to allow something like process a forks
process b, which forks process c.  In that scenario process c needs to
have a copy of process b's memory, not process a's.  That is not
possible to do, AFAICT, without actually copying memory, which defeats
the purpose.

This is all with Win32 APIs.  It may be possible to do something with
NT-specific code, as Robert mentioned, but I ran into problems even
there, too.

If people are under the impression that we haven't given fork
performance a lot of thought, they're wrong.  *I* could be wrong (and
would be thrilled to be wrong) but I don't think that improving fork
performance is an afternoon's work for some skilled programmer.

As far as the one shell for all proposal, there are already a few of
these things kicking around.  They're used for linux boot disks where
it is more advantageous to have one large executable with lots of
builtin functionality rather than one shell with lots of programs.

I sincerely doubt that I would ever be convinced to allow something
like this into the cygwin distribution.  It seems like it flys in the
face of cygwin's goal and would just be YA thing to confuse people.

cgf
--
Please do not send me personal email with cygwin questions.
Use the resources at http://cygwin.com/ .

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