www.delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin-developers/1998/04/03/10:57:36

From: cgf AT bbc DOT com (Christopher Faylor)
Subject: Re: Crazy fork idea
3 Apr 1998 10:57:36 -0800 :
Message-ID: <EqupBJ.44C.cygnus.cygwin32.developers@bbc.com>
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  <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.

>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."

- Raw text -


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