it is semantically incorrect for a process to cease to exist when in a state
like this, though. You'd have to really revise a lot of the ideas that 
the kernel is based around in order to make this do-able in a correct 
manner. Those devices that the processes were waiting on, for example, 
will not be in a cosistent state until the code that its waiting on is 
finished. if it never returns because of some kind of error, or busy 
device, or whatever, then it _should_ be hung. Now, if one fudged the
syscall such that whatever was being waited on in the verry innermost bit 
of code would fail with an error, and let that propagate out, it woudl 
release the other drivers and the process more cleanly. At some point, 
though, this practice too will lead to inconsistency, this time between 
the state of the device and what the driver thinks the state of the 
device is. best to leave it, in the practical sense.

isildur

On Sat, 9 Nov 2002, Alan Barrett wrote:

> On Fri, 08 Nov 2002, Julio Merino wrote:
> > "Jeremy C. Reed" <reed@reedmedia.net> wrote:
> > > Can someone point me to the code or documentation about why some
> > > processes won't be killed?
> > I do not know, but this is *very* *annoying*.
> 
> It sometimes helps to call revoke(2) on a pathname that refers to the
> device that is wedged.
> 
> Perhaps we need a new syscall to *really* kill a process, even if it's
> in a state where normal signal delivery does not happen.  Late 1980's
> Apollo Domain-OS had a "kill -lbolt" command that sent a "lightning
> bolt" that worked even where "kill -9" did not work.
> 
> --apb (Alan Barrett)
>