bug-coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] Replacement for the sigs_to_ignore hack in timeout.c


From: Giuseppe Scrivano
Subject: Re: [PATCH] Replacement for the sigs_to_ignore hack in timeout.c
Date: Fri, 10 Oct 2008 11:50:50 +0200
User-agent: Thunderbird 2.0.0.17 (Windows/20080914)

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,





reply via email to

[Prev in Thread] Current Thread [Next in Thread]