On Mon, 16 Jul 2007, Chuck Swiger wrote:

> On Jul 16, 2007, at 12:48 PM, Paul Goyette wrote:
>> Other than manipulating a process's signal mask (for example, using 
>> signal(3)), what can prevent delivery of a signal?
>> 
>> In particular, I've occassionally seen processes "hang" waiting for 
>> something (I/O completion?), and typing Control/C doesn't work.  Once the 
>> Control/C signal doesn't work, not even a `kill -KILL` can abort
>> that process!  Yet, if instead of typing Control/C first you simply
>> try `kill -KILL` then the target process is killed.
>> 
>> Can someone explain what's going on?
>
> Delivery of signals is done asyncronously during normal program execution; if 
> the process has context-switched out to execute a system call and is running 
> in the kernel instead, any additional signals will typically be held until 
> the process returns, but see "man siginterrupt"....

I understand that part.  But why would the target process be able to 
handle SIGKILL but not the signal created by Control/C (SIGSTOP? or is 
it SIGINT?)?  And why would Control/C prevent subsequent delivery of 
SIGKILL?