delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin-developers/1998/04/02/18:26:07

From: ian AT cygnus DOT com (Ian Lance Taylor)
Subject: Re: Crazy fork idea
2 Apr 1998 18:26:07 -0800 :
Message-ID: <199804030224.VAA05861.cygnus.cygwin32.developers@subrogation.cygnus.com>
References: <199804022354 DOT PAA00556 AT rtl DOT cygnus DOT com>
To: noer AT cygnus DOT com
Cc: cygwin32-developers AT cygnus DOT com, noer AT cygnus DOT com

   From: Geoffrey Noer <noer AT cygnus DOT com>
   Date: Thu, 2 Apr 1998 15:54:13 -0800 (PST)

   We could use shared memory for information like fds and mark it copy
   on write.  Then, when the parent process forks a child, the child
   could just keep using the same shared memory until such a time as it
   alters the information, at which time the OS would automatically
   create a copy and have the child modify that instead.

   Opinions?

Forget fds.  If copy on write is fairly fast, we can use it for the
heap, just like Unix does.  We shouldn't need a contiguous heap, so we
can just keep allocating new shared memory areas as the heap grows.
That might speed up forks quite a bit.

Of course, as always, we need a good profiler to really be sure.  It's
a moderately reliable rule of thumb that programmers are normally
mistaken about where their programs spend the most time.

Ian

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019