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: Sat, 29 Mar 2003 14:04:37 +0100
From: Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: Mozilla 1.3 built on cygwin?
Message-ID: <20030329130437.GH1207@cygbert.vinschen.de>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
References: <20030329001348 DOT GA1533 AT redhat DOT com> <LPEHIHGCJOAIPFLADJAHEEKLDHAA DOT chris AT atomice DOT net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <LPEHIHGCJOAIPFLADJAHEEKLDHAA.chris@atomice.net>
User-Agent: Mutt/1.4i

On Sat, Mar 29, 2003 at 11:18:37AM -0000, Chris January wrote:
> > >>You misremember.  I did hobble together a copy-on-write implementation
> > >>and found that it was actually slower.  The generic win32
> > >>implementation of copy-on-write isn't powerful enough to completely
> > >>implement fork anyway.
> > >
> > >Noone has explained, however, *why* the copy-on-write implementation
> > >was slower.  Perhaps we have just been using the wrong tests.  Does
> > >copy-on-write actually perform slower in "real world" tests?  I don't
> > >know, because I only used the skeleton example found in Nebbit's book.
> >
> > I implemented it with both the win32 api and with the skeleton example.
> > Neither was a speed daemon.  I can't think of a better test than doing a
> > bunch of forks and measuring the results.  Who knows why it is slower?
> > Maybe ReadProcessMemory is doing copy-on-write already or something.
> 
> For the record my own tests involved a single parent process forking, then
> sleeping for a set period of time and exiting. The child process wrote all
> over the heap while the parent was sleeping, thus forcing all of the shared
> pages to be copied. This was faster with Cygwin's fork than with the
> copy-on-write fork, even with Cygwin's extra process launching overhead, but
> I could not explain why. My copy-on-write fork code doesn't work on XP SP1
> so I can't retest right now.

And another FTR ("for the records"):  The copy-on-write on Win32 behaves
different from a copy-on-write on POSIX. 

On POSIX systems all child processes inherit the current memory content
from their own parent process and create their own copy only when itself
writing into that memory (fork semantics).

On Win32, the original state of the memory is treated as genuin state for
each process.  Therefore child processes don't inherit the changes from
their parent processes but instead they begin with a fresh unchanged memory
as it was before the first process wrote to it.

For that reason it is e. g. necessary to copy over the memory contents
explicitly from the parent to the child in case of mmap(MAP_PRIVATE)
(see mmap.cc (fixup_mmaps_after_fork)).

Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Developer                                mailto:cygwin AT cygwin DOT com
Red Hat, Inc.

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