martin@mwtech.UUCP (Martin Weitzel) (09/05/90)
[This thread started with a question, how zombies can be avoided,
if a process wants to create a child but has definitely no interrest
ever knowing what happened to this child and also doesn't want to
risc to be suspended by a wait(2) for a child.]
There original poster basically presented the following solution for
this problem:
parent does fork(2) to create first child
first child does fork(2) to chreate second child
second child does exec(2) the sub-process of interest
first child does exit(2)
[second child gets orphaned by this and at some later point
the wait(2) in /etc/init will clear its process table slot]
parent does wait(2) for first child
[and will continue immediatly, as first child doesn't live long]
Several other people have suggested:
signal(SIGCLD, SIG_IGN);
while again others pointed out valid reasons where this can be problematic.
It just occured to me that there might be a third alternative. The normal
sequence of system calls for process-creation is:
int pid, rc;
switch (pid = fork()) {
case -1:
/* handle error */
case 0:
/* child excutes here */
exec(...,...);
default:
/* parent excutes here */
while (wait(&rc) != pid) /*empty*/;
}
If the wait(2) in the default case is not desired we have the situation
that the original poster wanted to solve (zombies may accumulate in the
process table).
Now if we don't ever want to wait, what if we exec not in the child,
but in the parent process?
switch (pid = fork()) {
case -1:
/* handle error */
default:
/* parent excutes here */
exec(...,...);
case 0:
/* child executes here */
}
Of course, if the program is interactive and started from the shell, this
is no good idea as the shell now would no more wait for the right process,
but for a demon this may be a feasable way for creating processes for
which the creator never wants to wait, nor wants to fill the process
table with zombies.
Or did I overlook somthing?
--
Martin Weitzel, email: martin@mwtech.UUCP, voice: 49-(0)6151-6 56 83