From: cgf AT bbc DOT com (Christopher Faylor) Subject: Re: Crazy fork idea 3 Apr 1998 10:57:36 -0800 Message-ID: References: <199804022354 DOT PAA00556 AT rtl DOT cygnus DOT com> Reply-To: cgf AT bbc DOT com To: cygwin32-developers AT cygnus DOT com 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. >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. Oh, I don't know about that. I've got a getprotobyname() optimization coming up that I'm sure will be a tremendous performance boost for cygwin. Hmm... On second thought, maybe you're right... -- http://www.bbc.com/ cgf AT bbc DOT com "Strange how unreal VMS=>UNIX Solutions Boston Business Computing the real can be."