Re: RFC: [PATCH] ignore SIGINT&QUIT while waiting for external command

From: Dmitry Potapov <dpotapov@gmail.com>
Date: Oct 19, 2010, 16:31 UTC
Message-ID: <20101019163124.GB8065@dpotapov.dyndns.org>
In-Reply-To: <20101019133236.GA804@sigill.intra.peff.net>

On Tue, Oct 19, 2010 at 09:32:36AM -0400, Jeff King wrote:

Show 6 quoted lines

> 
>   2. Why do we want to do it only for the proxy-command case? If I have
>      a long-running external diff or merge helper, for example, what
>      should happen on SIGINT? Should we exit with the child still
>      potentially running, or should we actually be reaping the child
>      properly?

Probably, it should be done in other cases too. However, I am not sure if it should be done unconditionally. For instance, when we run a pager, I don't think we should ignore the signals just because we started a pager.

I agree that silent_exec_failure is not the best flag for that -- I was just trying to make minimal changes to the existing behavior, and if this flag is set, you seem always want to ignore these signals, but there are some other cases too as you pointed above.

Now, I think we should always ignore these signals when run_command() is used (similar to system()), but do not mask signals if start_command() is used (or make it optional by adding a new flag).

Show 7 quoted lines

> 
> we will overwrite the function pushed in the sigchain_push with a stale
> handler. I think you could just replace your signal() calls with:
> 
>   sigchain_push(SIGINT, SIG_IGN);
>   ...
>   sigchain_pop(SIGINT);

Yes, it is certainly better. I was not aware about these functions.

Dmitry