This is the mail archive of the
cygwin-patches@cygwin.com
mailing list for the Cygwin project.
Re: Signal handling tune up.
On Tue, Aug 19, 2003 at 09:06:45PM -0400, Pierre A. Humblet wrote:
>At 08:37 PM 8/19/2003 -0400, Christopher Faylor wrote:
>>On Tue, Aug 19, 2003 at 04:30:06PM -0400, Pierre A. Humblet wrote:
>>>Regarding your changes (it will take me a while to fully understand them)
>>>- What problem are you trying to solve by having a local sigtodo?
>>> Specifically now that you have removed the thisproc argument in
>sig_handle,
>>> rc is not used in any function call and I don't see why it's helpful
>>> to segregate signals on a per source basis.
>>
>>>On Tue, Aug 19, 2003 at 12:22:17AM -0400, Christopher Faylor wrote:
>>>>Oh, right. I was remembering a time when the inner while used to
>>>>exhaust the InterlockedDecrement. It doesn't do that anymore but that
>>>>hardly matters because, as you say, it is possible to the current code
>>>>to be confused by "simultaneous" signals coming from the outside and
>>>>from the current process.
>>>>
>>>>The only way I can think of around that is to add another an internal
>>>>sigtodo array to every process just for signals sent to myself and scan
>>>>that and the sigtodo process table. I guess I'll implement that in the
>>>>next couple of days.
>
>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.
>Now that you have gotten rid of that I don't see any confusion
>left and I don't see the reason for the local sigtodo.
>
>>>- Having low_priority_sleep (SLEEP_0_STAY_LOW) in the sigthread loop
>>> leaves it running (and WFMOing) at low priority.
>>
>>How is moving it into the sigthread loop any different than having it
>>where it was previously? The point was for the sigthread loop to
>>take a nap for a while and give the main thread a chance to wake up.
>
>For two reasons:
>- Taking a nap is not useful if the mainthread is waiting for
>a semaphore from the sigthread. The nap should occur after the
>semaphore has been signaled.
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.
As I said previously, I am going to have to dissect your patch and look
at it in more detail. I haven't done that yet. I thought you were
implying that my move caused a functional difference. If you want,
I'll remove the "suggested by Pierre Humblet" from the ChangeLog.
>>>Also, as you wrote the signal code is not as simple as a bicycle! A
>>>question I have is why it's helpful to call
>>>thisframe.call_signal_handler in sig_dispatch_pending. I was under the
>>>impression that something like it would happen automagically on return.
>>
>>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.
cgf