fork() idea

Christopher Faylor cgf@redhat.com
Mon Jan 28 22:27:00 GMT 2002


On Tue, Jan 29, 2002 at 10:21:37AM +1100, Robert Collins wrote:
>
>===
>----- Original Message -----
>From: "Christopher Faylor" <cgf@redhat.com>
>
>
>> On Sun, Jan 27, 2002 at 11:28:48PM +1100, Robert Collins wrote:
>> >Just running this past for criticism.
>> >
>> >What if on fork(), we loaded a _trivial_  stub program, what depends
>on
>> >little-or-nothing, and thus takes up almost no memory, has little
>chance
>> >of dll conflicts, address relocation etc. Then allocate memory to
>look
>> >like the parent, load .dll's etc.
>>
>> I've toyed with this from time to time but I don't think it is a win.
>> When you do a fork with the current implementation all of the text
>> section will be read from memory and all of the data section will be
>> copied from disk.
>
>Ok, can the text section be done via COW?

There's no need.  It is already mapped directly from memory, if I
understand the way things work.  The read-only sections just get
remapped when a new process is started.  It's only the non-readonly
pages that are copied from disk.

>>If you just start a stub, then you have to get the text section from
>>somewhere.  AFAIK, you can't remap the memory from one process to
>>another so you actually have to read from disk.  You could map it in
>>but I don't think that is guaranteed to be read directly from memory.
>
>I'm suggesting that the text section and data section are read into a
>named shared memory segment, thus allowing them to be mapped straight
>in (and as the parents text section is in the same mapped area, it will
>come from memory (as the parent is in memory :]).

Linear inheritance still doesn't work in this scenario:

proc a forks		moves its data seg into a COW section
   proc b forks		inherits the section from proc a
     proc c forks	inherits the section, effectively from proc a

That's how COW works on Windows.

Or, that is how it could work on NT.  It doesn't work even that well on
Windows 9x.

cgf



More information about the Cygwin-developers mailing list