Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!brutus.cs.uiuc.edu!ux1.cso.uiuc.edu!tuna.cso.uiuc.edu!kline
From: kline@tuna.cso.uiuc.edu (Charley Kline)
Newsgroups: comp.unix.ultrix
Subject: Re: Firing up a process and not wait()ing on it..
Message-ID: <1989Dec21.184746.7641@ux1.cso.uiuc.edu>
Date: 21 Dec 89 18:47:46 GMT
References: <32382@news.Think.COM> <1989Dec19.191032.21857@lavaca.uh.edu> <2308@bacchus.dec.com>
Sender: news@ux1.cso.uiuc.edu (News)
Distribution: na
Organization: University of Illinois at Urbana-Champaign
Lines: 38

> 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@uiuc.edu
uunet!uiucuxc!kline

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