At 08:58 PM 8/18/2003 -0400, Christopher Faylor wrote: >On Mon, Aug 18, 2003 at 08:17:36PM -0400, Pierre A. Humblet wrote: >>5) >>This is just an observation, about sig_handle (int sig, bool thisproc) >>The thisproc argument is set to "rc != 2" in the sigthread. However >>it is possible for several signals to occur simultaneously and a >>signal can be processed with rc == 2 even when generated by the >>current process (or conversely). This could cause a SIGINT to be >>ignored (or not) when it shouldn't (something like that was discussed >>on the list recently). >>I don't fully understand the use of thisproc and have no suggestion. > >Are you saying that that someone reported execing a process, hitting >ctrl-c, and having another process simultaneously sending CTRL-C's to >the exec'ed stub? I have a hard time seeing how that could be a common >occurrence.
No. But you just explained what I didn't understand about the code. >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. I don't understand their role. Pierre