www.delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin-developers/1998/04/03/13:07:03

From: lhall AT rfk DOT com (Larry Hall)
Subject: Re: Crazy fork idea
3 Apr 1998 13:07:03 -0800 :
Message-ID: <3.0.5.32.19980403153333.0093e960.cygnus.cygwin32.developers@pop.ma.ultranet.com>
References: <EqupBJ DOT 44C AT bbc DOT com>
Mime-Version: 1.0
To: cgf AT bbc DOT com, cygwin32-developers AT cygnus DOT com

At 06:42 PM 4/3/98 GMT, Christopher Faylor wrote:
>In article <199804030224 DOT VAA05861 AT subrogation DOT cygnus DOT com>,
>Ian Lance Taylor  <ian AT cygnus DOT com> wrote:
>>   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.
>
>The last time I timed mmapped allocation on various UNIX systems I found
>that there was a performance penalty for using mmap when compared to
>"standard" sbrk allocation.  Assuming that I did the timings correctly,
>of course...
>
>It would be interesting to try, though.  There is already an option for
>using mmap() for large blocks in newlib's malloc.  Dunno if it works
>on cygwin, though.
>
>I wonder if it would be possible to move the data segment to shared
>memory, too.  Then a fork would just mean resetting an DS register?
>
>Also, there is some discussion about NT internals at the site
>www.nternals.com.  Rumor has it that there is some kind of equivalent
>to UNIX fork already in the NT kernel.  It is just not documented.
>The information at this site talks a little about the low level calls
>but does not give specific information.

I haven't looked at the ntinternals site that Chris suggests but according
to Rajeev Nagar in "Windows NT File System Internals", the NT Virtual 
Memory Manager maintains what's called a Virtual Address Descriptor (VAD)
for every block of memory allocated for a process.  This VAD has attributes
that contain information about, among other things, whether the 
copy-on-write feature has been enabled for a range of pages.  Rajeev then
says:

  "The copy-on-write feature allows efficient support for POSIX-style
   fork() operations, in which the address space is initially shared by
   parent and child processes.  If, however, either the parent or children
   try to modify a page, a private copy is created for the process 
   performing the modification."

This seems to support the "rumor" Chris was referring to.


Larry Hall                              lhall AT rfk DOT com
RFK Partners, Inc.                      (781) 239-1053
8 Grove Street                          (781) 239-1655 - FAX
Wellesley, MA  02181                    http://www.rfk.com

- Raw text -


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