Mailing-List: contact cygwin-developers-help AT sourceware DOT cygnus DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-developers-owner AT sourceware DOT cygnus DOT com Delivered-To: mailing list cygwin-developers AT sourceware DOT cygnus DOT com Date: Wed, 5 Jul 2000 22:26:07 -0400 From: Chris Faylor To: cygwin-developers AT sourceware DOT cygnus DOT com Subject: Re: copy-on-write (oh well) Message-ID: <20000705222607.A18846@cygnus.com> Reply-To: cygwin-developers AT sourceware DOT cygnus DOT com Mail-Followup-To: cygwin-developers AT sourceware DOT cygnus DOT com References: <20000703225357 DOT A25565 AT cygnus DOT com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <20000703225357.A25565@cygnus.com>; from cgf on Mon, Jul 03, 2000 at 10:53:57PM -0400 On Mon, Jul 03, 2000 at 10:53:57PM -0400, cgf wrote: >I spent part of my "day off" today hacking together a "copy-on-write" >implementation for copying the heap after a fork. I've long wanted to >try to do something like this. It seems to work pretty well as long as >I don't fork something that forks something else. > >I can't tell if there is a performance improvement or degradation or not >yet. > >I hope that nobody is standing while reading this because I have some >shocking news. > >The copy-on-write functionality is badly broken on Windows 95, so I >can't use it there. This only works on NT. I couldn't figure out how to get copy-on-write working beyond the first level of fork. There doesn't seem to be any way to share a pool of memory inherited from a parent process and potentially updated with a copy-on-write operation. It turns out not to matter anyway. The current version of fork is somehow, inexplicably faster than my copy-on-write version. I also tried having the child process inherit the parent's memory and just memcpy'ing the parent's memory into the child's malloc pool. That was the slowest of all. Oh well. cgf