Eric J. Korpela writes:
>
> >
> >
> > : 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?
>
> No, that's what fork() does on modern machines. vfork() was developed back
> in the days when fork() actually did do a fully copy of the data segment,
> the way it's done in elks. This is a waste when you're forking for the
> purpose of calling exec and waiting until the child exits. From the (SunOS 4)
> man page:
>
> vfork() differs
> from fork() in that the child borrows the parent's memory
> and thread of control until a call to execve(2V), or an exit
> (either by a call to exit(2V) or abnormally.) The parent
> process is suspended while the child is using its resources.
>
>
> which basically means that the parent gets suspended, the child uses
> the parent's data segment until the execve() call at which point a new data
> segment is allocated for the child process and the parent is allowed to
> resume.
>
This is essentially what I have done. The only problem with doing this is
that when fork() returns to the child, and the child calls exec(), the stack
will be modified, so when the parent comes to return from fork(), it will
crash, or at best do something odd.
The scheme I am using at the moment, that of copying the bottom 100 bytes
of the stack for the child to use, works, but does not really offer any
kind of safety net. Is it fair to just accept that if a process vfork()s,
and does not exec or exit, but instead carries on, it may well crash?
Also 100 bytes is quite alot of stack. Any opinions on what would be a more
sensible, but still safe ammount?
Al
