Signal handling tune up.

Pierre A. Humblet
Wed Aug 20 01:08:00 GMT 2003

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
>>  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"
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.
- When the sleep is at the top of the loop it is before the statement
that sets the sigthread priority to a high value. And the WFMO occurs
while the thread has high priority, which is important.

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

More information about the Cygwin-patches mailing list