This is the mail archive of the
mailing list for the Cygwin project.
Re: Signal handling tune up.
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.
>- 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.
>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.