Re: SIGINT handling

[Chet Ramey]

On 9/21/15 5:07 PM, Stephane Chazelas wrote:

> The problem is that here the parent's SIGINT handler is run upon
> the return from waitpid(), just after. My patch doesn't rely on
> EINTR from waitpid() (which doesn't happen here, waitpid() returns
> with the pid of the child that did an exit() upon receiving
> SIGINT), just on the "status" returned by the child, so doesn't
> have the problem.

I wonder if the kernel is restarting the waitpid() even though the
signal handler was installed without SA_RESTART.

> What do you suggest we do to fix that issue?

I think your additional test for wait_sigint_received coupled with a
check that the child died for some other reason than SIGINT, in addition
to the EINTR test, is a reasonable fix.

>> This still counts as catching and handling the SIGINT, and the shell
>> should not act as if the foreground process died as a result of one.
> 
> That's the point I'm arguing on.
> 
> If the command handled SIGINT and returned with 130, I argue it
> is considering itself and telling its parent as having been
> "interrupted"

No, it's not.  If a shell exits with status 130, it's saying that the last
command it executed was killed by SIGINT, or happened to exit with status
130 for some random reason.  It's very possible for a non-interactive
shell to restore its original SIGINT handler and resend SIGINT to itself,
if it's concerned about telling its parent that it's been interrupted.

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRU    chet@case.edu    http://cnswww.cns.cwru.edu/~chet/