This is the mail archive of the cygwin-developers@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: fork() idea


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.

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.

>The point of this being that it allows a neat hack:
>System shared memory can be made copy on writewith FILE_MAP_COPY. On
>WinNT, if we load the application image into system mapped memory, we
>can then duplicate much/most of the address space with _much_ lower
>overhead.
>
>Thoughts?

copy-on-write is already a to-do but I played around with this a lot a
couple of years ago and came to the conclusion that the win32 api
implementation is not enough to accomplish this.  For one thing, I
couldn't get things working in a scenario where a process forks a
process which forks another process.  I actually got a copy-on-write
version of fork working for the simple "process forks process" case but
it was not any faster.  I expected some improvement over the current
ReadProcessMemory method even though I was still copying a data section
in and remapping it.

It is possible to get this working with the low-level Nt calls, but
I didn't want to skew cygwin sources that badly.

cgf


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]