Re: Signal handling tune up.

[Christopher Faylor <cgf at redhat dot com>]

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.

cgf