vfork() is part of XPG4-UNIX
All memory is shared, including the stack. The child must not
return from the current function or call exit(), but may call _exit().
Signals sent to the parent do not arrive until after the child does
execve() or _exit(). (seems OK in 2.2.0-pre6)
Example: after vfork() the child can send SIGKILL to the parent
twice (or more) without error. The parent dies after the child
does execve() or _exit(). (seems OK in 2.2.0-pre6)
Signal handlers are inherited, but not shared. If you set up a signal
handler called sh1() then vfork() and kill() both processes, both
processes will use sh1(). Of course, signals to the parent arrive
after the child releases the parent. If the child changes the signal
handler to sh2() after the vfork(), the child uses sh2() while the
parent still uses sh1(). (seems OK in 2.2.0-pre6)
Also, from the Ultrix (old BSD) and SCO Unixware (new SysV) man pages:
To avoid a possible deadlock situation, processes which are children
in the middle of a vfork are never sent SIGTTOU or SIGTTIN signals.
Rather, output or ioctl() operations are allowed, and input attempts
result in an end-of-file indication. (not tested on Linux)
Experimentation shows that if the child uses kill() to send itself
a SIGTTIN signal, kill() will return without error and the signal will
never be delivered. (seems OK in 2.2.0-pre6)
According to Sun (Solaris 7):
In a multithreaded application, vfork() borrows only the thread of
control that called vfork() in the parent; that is, the child
contains only one thread. (not tested on Linux)
That leaves only 2 behaviors left to verify.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/