edler@cmcl2.UUCP (01/12/84)
Can anyone think of a reason why it is important for init to become the "parent" of processes whose real parents have exited without waiting for them? It would seem simpler to just mark such orphans in some way (set their p_ppid to 0 or their p_pptr to NULL or set a flag) so that when they exit, they clean themselves up (i.e. they don't become zombies at all). Jan Edler cmcl2!edler (New York University) edler@nyu (212) 460-7314
rpw3@fortune.UUCP (01/14/84)
#R:cmcl2:-127700:fortune:11600041:000:1083
fortune!rpw3 Jan 13 14:25:00 1984
Must 'init' inherit orphans?
If the wait(2) call returned anything more than status, such as accounting,
it might be important, but accounting is handled by the kernel directly.
It just seems to be a case of the usual UNIX "well, we've got this way
to clean up processes with wait(2), and init's always doing a wait, so..."
It IS important that orphans lose their process groups, so signals from
the terminal don't screw with background jobs. Back before setpgrp(2),
the standard idiom for "clear pgrp" was (and is):
if (fork()) /* parent */
wait(NIL);
else if(fork()) /* first generation */
exit(0); /* send Moses down the river */
else /* second generation */
...do work....
Orphans "inherit" init's pgrp, which is "none". But I don't see any
reason that you couldn't do it in the kernel. On the other hand, what
does it cost for init to do it? Well, init must swap in. What else? ...
Rob Warnock
UUCP: {sri-unix,amd70,hpda,harpo,ihnp4,allegra}!fortune!rpw3
DDD: (415)595-8444
USPS: Fortune Systems Corp, 101 Twin Dolphins Drive, Redwood City, CA 94065