In article <81D89ECB-40B6-499D-A49B-BC9FB584CC8D@mac.com>,
Chuck Swiger  <cswiger@mac.com> wrote:
>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.

That is ^Z, ^C generates SIGINT. stty -a will tell you the current
settings. You care about "susp" and "intr".

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

Non realtime signals are not queued, they are kept in a bitmask.
Lower numbered signals are delivered first.

christos