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: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" 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 wrote: >> From: Geoffrey Noer >> 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