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