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

        Ok.  When vfork() is called, save the stack pointer in the kernel.
Then, when the child calls exec(), more items are stored on the stack. (at
least the return address from the exec call)
        When the parent is rescheduled, the system can reset the stack pointer
to the value it was when vfork was called, providing that it the child
never returned from the procedure that called fork, but instead called exec from 
there...



: 
: 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?
: 

        It's not acceptable to carry on and crash.
Greg

Reply via email to