Re: vfork() behavior notes
Perry Harrington (pedward@sun4.apsoft.com)
Mon, 11 Jan 1999 10:13:56 -0800 (PST)
> 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.
The implementation of vfork uses the task structure to block the parent.
This means that a clone()d thread can execute vfork. Since under Linux
a clone()d thread is a separate scheduler process, the thread is blocked
and the init-child process will still runs (as well as the rest of the
threads).
However, as Murphy always turns everything upside down, this will be tested
(I'm gonna sync up tonight and try this when pre7 comes out).
--Perry
--
Perry Harrington Linux rules all OSes. APSoft ()
email: perry@apsoft.com Think Blue. /\
-
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/