This is the mail archive of the
mailing list for the Cygwin project.
Re: Signal handling tune up.
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
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,
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
If nothing special is done, the handler will start when
By calling sigframe::call_signal_handler () the handler gets
called just before the return. What's the gain?