Clifford Heath
3/15/2007 11:41:00 PM
Greg Hurrell wrote:
> why does popen3 use this child/grandchild model?
It orphans the child process, so its parent doesn't need to clean
it up when it dies. Instead, the process is adopted by "init",
which is process-id 1, which takes responsibility for the cadaver.
To run completely isolated from the calling process' environment,
it must become a leader of a new process group and drop its
controlling terminal. In BSD-derived system, the latter can be
done by calling the TIOCNTTY ioctl, and the latter via setgprp().
On AT&T UNIX systems however, setpgrp performs both functions,
but only if it's the first time this call has been made in this
process. As a result, it must first fork(), then setpgrp(), then
fork again.
I'm not sure whether all this is completely relevant to popen3,
but there might be subtle issues on some systems if the code
was changed to use only one fork. For example, on some Unix
systems, a terminal (tty) device doesn't become available until
the no process has that tty as a controlling tty - so "login"
can't issue a login prompt. If you pipe output to a command and
then exit while it continues to process that data, then the user
logs out, no-one won't be able to log in again on that tty until
the background process exits.
All this was thoroughly examined by Dave Lennert in his classic
1987 posting entitled "How to write a Unix Daemon" to the HP
internal newsgroup "hp.unix", which I archived and still have.
The paper was also published in ";login:", Volume 12 No 4,
July/August 1987. The paper seems rather hard to find online now.
Clifford Heath.