On Tue, 27 Jul 1999, Greg Haerr wrote:
> : The parent process's data segment is not copied, just re-alloced, and
> : rather than returning to the parrent process, fork sleeps on the parents
> : child_wait wait queue.
>
> Let me try to remind myself of the vfork semantics.... Basically,
> rather than copying the data segment on real computers the OS sets the
> data segment page tables to copy-on-write, so that the data segment
> copy time and space is saved, since it's all going to be replaced by
> the following exec, right?
Not quite.
It was, I think, initially implemented for machines which couldn't
do any form of COW for memory accesses. The semantics are somewhat
ugly, but the intention (and where it is most useful) is that the
parent sleeps until the child exec()s, and that no copying takes
place.
Data changes which the child makes may or may not be available to
the parent when it wakes up, but usually are.
> : All this seems to work just fine, but to make sure the parents stack
> : does not get corrupted by the child before it execs, I make a copy
> : of the bottom 100 bytes on the stack, below the stack, for the child to
> : use.
I believe that this should be unnecessary. It should suffice
to fix vfork() and exec() so that they don't trash the stack
(if that's what's actually happening).
Matthew.
