On Jul 16, 2007, at 1:14 PM, Paul Goyette wrote:
>> 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?

Control-C generates SIGTSTP, rather than SIGSTOP.
The former signal can be caught or ignored, the latter cannot.

I suspect that if the first pending signal is SIGKILL or something  
else which cannot be caught or ignored, then the effect of that  
signal happens immediately (which is the intention); however, if the  
process is in a syscall where normal signal delivery is held until  
return, and you deliver such a signal and then a SIGKILL, the second  
pending signal is queued behind the first signal rather than being  
processed immediately.

Perhaps one of the local gurus can provide more details specific to  
NetBSD...?  :-)

-- 
-Chuck