Signal handling tune up.

Pierre A. Humblet pierre@phumblet.no-ip.org
Wed Aug 20 02:36:00 GMT 2003


I got blocked from the list for the second time today,
so I changed my address. Mail sent to the old one will
still get to me.

At 09:16 PM 8/19/2003 -0400, Christopher Faylor wrote:
>>
>>Yep. But the 'confusion by "simultaneous" signals' was due to
>>thisproc which was set to "rc == 2"
>
>No.  The confusion could result from two signals coming in at the nearly
>the same time, one from an external source and one from internal.  In
>that case wait_sig had no way of telling which signal was which and
>could end up either not setting a completion event or setting it
>erroneously.

OK, I trust you although I don't see it.
 
>I think we're talking about different things.  The only thing I did was
>move the existing code out of setup_handler and into wait_sig.  There
>should be very little functional difference in doing this.

Right. You did 50% of that particular change and I got worried. I will
try to relax.

>>>Not necessarily.  It depends on who is calling sig_dispatch_pending.  An
>>>outer sigframe user wins.  This guarantees that signals will be
>>>dispatched in sig_dispatch_pending.
>>
>>Thanks, but it's still greek to me. What is an "outer sigframe user".
>
>Someone who calls sigframe earlier in the call stack.

Still desperately trying to understand (I should stick to bicycles, 
I guess).
sig_dispatch_pending builds a sigframe. It will be found by 
setup_handler, which will call interrupt_on_return,
which will spoof the return address and call interrupt_setup to
build sigsave.
If nothing special is done, the handler will start when  
sig_dispatch_pending returns.
By calling sigframe::call_signal_handler () the handler gets
called just before the return. What's the gain?

Pierre 



More information about the Cygwin-patches mailing list