This is the mail archive of the cygwin@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Mozilla 1.3 built on cygwin?


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/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]