Hi Pádraig, I think that the only problem can raise when the sent signal is received by the monitor process after the handler is reinstalled. In that case the signal will be dispatched again to the process group. This can repeat again and again until it is finally ignored by the monitor process.
On http://www.opengroup.org/onlinepubs/009695399/functions/kill.html I can see in the "Rationale" section: "There was initially strong sentiment to specify that, if pid specifies that a signal be sent to the calling process and that signal is not blocked, that signal would be delivered before kill() returns. This would permit a process to call kill() and be guaranteed that the call never return. ...... Such modifications have the effect of satisfying the stronger requirement, at least when sigaction() is used, but not necessarily when signal() is used." So I guess the case I described before shouldn't happen. Regards, Giuseppe Pádraig Brady wrote: > Pádraig Brady wrote: >> Giuseppe Scrivano wrote: >>> Hello, >>> >>> what do you think about the following way to remove the sigs_to_ignore >>> hack in the timeout.c file? >>> It ignores temporarily the signal inside the `send_sig' function instead >>> of using the `sigs_to_ignore' array. >> I'll test this tonight, as this stuff is tricky. > > I tested it and couldn't break it, > though I'm worried about this change. > > The code it replaces is very simple and explicit. > Whereas I'm worried about the implicit behaviour > of the new code. Specifically I'm worried about > races, where the monitor process may not receive > (and ignore) the signal before the signal handler > is reinstated. I.E. are we always guaranteed that > kill() is synchronous and will not return until > all signals have been delivered to all members of group? > > thanks, > Pádraig, _______________________________________________ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
