Signal handling tune up.
Tue Aug 19 02:46:00 GMT 2003
On Mon, Aug 18, 2003 at 10:29:27PM -0400, Pierre A. Humblet wrote:
>>However, this does demonstrate a flaw in wait_sig. It exhausts the sigtodo
>>array based on he last received type of signal. So, if process a sends ctrl-c
>>to itself and "at the same time" process b sends ctrl-c to process a,
>>then the signal will be randomly processed as coming from either process a
>>process b. If the signal is handled as coming from process b, process a
>>will never get the notification it needs.
>Yes, that's what I had in mind. There are also the sig_dispatch_pending (0)
>in net.cc (and other places) that generate events with rc == 2 even though
>they are local.
Hmm. Now that I look at this more, I think maybe this should be a
'rc == 1' rather than a 'rc != 2'.
>I don't understand their role.
All of the calls in net.cc are sig_dispatch_pending (0).
It's supposed to synchronously flush all pending signals. Only calling
sig_dispatch_pending (1) should call the nonsync semaphore. This
justwake semaphore is problematic as it is used in exceptions.cc,
though. It will confuse wait_sig when signals are stacked up. That may
explain the occasional signal hang reports.
More information about the Cygwin-patches