Re: signal handling and delivery question

In article <81D89ECB-40B6-499D-A49B-BC9FB584CC8Dmac.com>,
Chuck Swiger  <cswigermac.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

On Jul 16, 2007, at 2:44 PM, Christos Zoulas wrote:
>> 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".

Yes, you're right.

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

OK, thanks for the details.  In Mach, events which become
BSD signals  
are queued as messages to the exception port of a task if it
is in  
the middle of a system call, and are dequeued as/when the
task  
becomes runnable again.

-- 
-Chuck