> :
: > : 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.
:
: I can't yet work out a way to make sure this can't happen. We could set up
: some kind of timer that kills the child if it does not exec, or watch it to
: see if it shrinks its stack to much and kill it then.
:
We need to agree on the semantics of vfork(). If the process
calling vfork() isn't allowed to call any other system call after vfork other than
exec() or maybe some dup() calls, then you're version could work.
If the calling process declares more than 100 bytes of stack and
returns from that procedure, you're crashed, even if it later calls exec.
I still don't see what's wrong with my first suggestion - don't allow
the caller to return from the procedure that it called vfork() from. Then, the stack
doesn't need to be copied, and system calls don't need to be monitored. The
stack frame will be ok when the parent returns from vfork().
Greg
