Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84 SMI; site sun.uucp Path: utzoo!linus!philabs!cmcl2!seismo!harvard!talcott!panda!genrad!decvax!decwrl!sun!shannon From: shannon@sun.uucp (Bill Shannon) Newsgroups: net.unix-wizards Subject: Re: WAITing for specific process Message-ID: <2568@sun.uucp> Date: Tue, 6-Aug-85 04:16:52 EDT Article-I.D.: sun.2568 Posted: Tue Aug 6 04:16:52 1985 Date-Received: Sat, 10-Aug-85 04:58:48 EDT References: <106@ihuxj.UUCP> <406@brl-tgr.ARPA> Distribution: net Organization: Sun Microsystems, Inc. Lines: 46 > > The wait() system call returns the process id of zombie child, but a > > process may have more than one of these outstanding at a time. Wait() > > is free (it appears) to return the pid of any of these zombie children. > > What if you want to wait for a particular child? ... > The facility IS provided, to some degree: > > void > waitfor( pid ) /* wait for process to exit */ > int pid; /* ID of process to wait on */ > { > extern unsigned sleep(); > #define DELAY 2 /* test interval, in seconds */ > > while ( kill( pid, 0 ) == 0 ) > sleep( (unsigned)DELAY ); > } Polling for a child's death is really gross. If the child will run for a long time, this keeps the parent "hot" (in memory) and wastes cpu time. If the child will finish quickly this wastes real time. > The only children your process should have other than > those it created itself are the ones it is given by the shell when > it is last in a pipeline. It doesn't matter if you eat those zombies. Ah, but what about the processes created by library routines that you called? As you start to build larger programs that make heavy use of multiple processes (both directly in the program itself and indirectly in library routines called by the program) you discover that the existing facilities provided by UNIX are not nearly powerful enough to allow all the users of sub-processes to cooperate without interfering with each other. However, they are powerful enough to build such a facility on top of. What's needed is the ability to start a process and be notified of its termination, without interfering with any other such uses by other parts of the same parent process. A list of terminated processes' statuses needs to be kept in the parent process, so that it can be examined by something like the "waitfor" proposed above. Switching to such a mechanism almost certainly precludes the standard use of wait(), SIGCHLD, etc. A layer on top of them is needed and everyone needs to be convinced to use only that layer (e.g. fread vs. read). Maybe we should entertain proposals for such a layer? Bill Shannon