> 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.

The problem isn't getting rid of the process; that would be fairly
easy.  The problem is that processes stuck in states like this actually
represent places in the kernel where code assumes something will happen
"soon" and it just isn't happening.  ("something" typically means
something like a device resetting.)  Blowing away the process context
in which such things could potentially happen will usually leave
something inconsistent.

For example, consider the tape drive example someone mentioned.  The
process could be nuked, yes, by fiddling data structures.  But that
would leave the tape in a state that's inconsistent with what the
driver thinks is possible.  I would not be surprised to find the driver
panicking next time you touched the tape drive, and it's not clear to
me this is any better than having a stuck process holding it busy.

Essentially, such behaviour can be looked on as indicating bugs in the
kernel: either places where two parts of the kernel disagree about the
interface between them, if the problem is purely software, or where the
kernel's model of the outside world (typically device hardware) does
not match the way that world actually behaves.  (There is actually a
third possibility, which is basically that the kernel is cheating by
making some operation uninterruptible when it's just a SMOP to make it
interruptible and someone didn't go to the effort.  An example might be
certain operations on a dead NFS server.  Admittedly, in some of these
cases the "SMOP" could be comparatively large, such as a complete
redesign of some subsystem.)

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B