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