Firing up a process and not wait()ing on it..

Charley Kline kline at tuna.cso.uiuc.edu
Fri Dec 22 05:47:46 AEST 1989


> Don't you still have to wait() for it to prevent the child process from
> becoming a zombie when it exits?

The sleazy way around this is to

    ...
    if (!fork()) {
	if (!fork()) {
	    execl("/usr/bin/foo", "foo", "bar", 0);
	    _exit(1);  /* in case exec fails */
	    }
	exit(0);       /* exit child */
	}
    wait(0);
    ...

This double fork creates a child, which creates a grandchild, which
execs the desired program. The child exits without waiting on the
grandchild, thus the init process inherits the grandchild and will
wait() for it.  The parent then waits for the child, and since the
child exits very quickly, the parent can continue in short order. Of
course this isolates the parent from the grandchild, so the parent
can't get any exit status information from the grandchild process.


Of course the more proper way to do this is to create a SIGCHLD handler
which, when fired, does a wait3() with the WNOHANG option in a loop
until -1 is returned, then resets the signal and returns. This way the
parent waits for the children as it's supposed to (and can get status
information from the child).

Yours in Section 2,
_____
Charley Kline, University of Illinois Computing Services
c-kline at uiuc.edu
uunet!uiucuxc!kline

"Oh Bliss! Oh Rapture!"  "Oh Rapture! Oh Bliss!"



More information about the Comp.unix.ultrix mailing list