Path: utzoo!utgpu!watmath!att!pacbell!well!nagle
From: nagle@well.UUCP (John Nagle)
Newsgroups: comp.unix.wizards
Subject: Re: when does kill -9 pid not work?
Message-ID: <13056@well.UUCP>
Date: 8 Aug 89 17:22:32 GMT
References: <20532@adm.BRL.MIL>
Reply-To: nagle@well.UUCP (John Nagle)
Lines: 26


     OK.  What's going on here is simple, but has several parts.

     First, you can send a signal, including signal 9, to a process at
any time.  But no action is taken on a signal until the receiving
process is in a position to receive signals, with control in user space.
So, in general, if you send a signal to a process while the process is
making a system call, the signal will not be processed until the
system call is completed.  This protects the internal consistency of
the kernel's tables.  (Historical note: In TOPS-20, you could kill a
process while it was making a system call.  This made for an interesting
kernel architecture.  UNIX is simpler internally because this is disallowed.)

     Thus, if a process is making a system call, and the system call
has resulted in a wait within the kernel, sending a signal to that process
will have no effect until the wait completes.  

      However, to prevent processes from remaining stuck at some well-known
wait points, such as waiting for input from a terminal, there is special
code within the kernel so that some specific wait conditions are checked
for when a signal is sent, and the kernel will abort those waits.
I don't have access to kernel sources here, so I can't check this,
but I think that all kernel-buffered character device waits can be
escaped.  SELECT is also escapable via signal, as I recall.

					John Nagle