Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!linus!security!genrad!decvax!duke!phs!sdyer@bbncca.ARPA (Steve Dyer)
From: sdyer@bbncca.ARPA
Newsgroups: net.unix
Subject: Re: blocking on `exit'
Message-ID: <342@bbncca.UUCP>
Date: Wed, 23-Nov-83 03:07:08 EST
Article-I.D.: bbncca.342
Posted: Wed Nov 23 03:07:08 1983
Date-Received: Sun, 27-Nov-83 03:13:37 EST
Lines: 31

References: <530@sbcs.UUCP>
Relay-Version:version B 2.10.1 6/24/83; site duke.UUCP
Posting-Version:version B 2.10 5/3/83; site bbncca.ARPA
Path:duke!decvax!genrad!wjh12!bbncca!sdyer
Message-ID:<342@bbncca.ARPA>
Date:Wed, 23-Nov-83 03:07:08 EST
Organization:Bolt, Beranek and Newman, Cambridge, Ma.

I think you have two questions:

First, processes which exit successfully, but have not yet been waited for,
still take up a process slot (from which the wait system call takes its
information.)  But, they really ARE dead and are not blocking on anything
(in the strict sense of the term.)  The "Z" in "ps" stands for "zombie".
Once the parent process gets around to waiting for it, the process slot
is freed up.

There ARE situations where a process could in fact block in an exit system
call, most usually due to insufficient error handling in a device driver.
closef() is called within exit() for each open file the process had.
If this implicitly invokes a device-specific close routine which blocks
forever because of some problem, then the process will indeed hang
(and killing the process doesn't necessarily fix it, but rather causes
it to reenter exit(), blocking once again.)  Mostly these have occurred
in drivers which we've touched or modified in some way (I can think of this
occuring in an early cut of a TTY driver.)  I don't think it's a problem
with vanilla UNIX systems, though I may be corrected on this.
--
/Steve Dyer
decvax!bbncca!sdyer
sdyer@bbncca