Re: [PATCH 00/17] Interrupting programs that block/ignore SIGINT

[Eli Zaretskii via Gdb-patches <gdb-patches@sourceware.org>]

Ping!  I don't think I received any responses for the below.  Can we
please discuss this?  TIA.

> From: eliz@gnu.org (Eli Zaretskii)
> Date: Thu, 03 Jun 2021 22:51:05 +0300
> 
> > From: Pedro Alves <pedro@palves.net>
> > Date: Thu,  3 Jun 2021 20:02:26 +0100
> > 
> > Currently, on GNU/Linux, it is not possible to interrupt with Ctrl-C
> > programs that block or ignore SIGINT, with e.g., sigprocmask or
> > signal(SIGINT, SIG_IGN).  You type Ctrl-C, but nothing happens.
> 
> I'm not sure I understand why this is a problem.  If a debuggee blocks
> or ignores SIGINT, then SIGINT cannot be used to stop it, neither when
> it runs outside the debugger nor when it runs under a debugger.  There
> are enough other methods to stop such a debuggee (e.g., send it a
> different signal), but basically such a program clearly tells that it
> doesn't want to be interrupted by SIGINT, period.
> 
> Btw, what about programs that install a SIGINT handler that does
> something when SIGINT is delivered, but don't block or ignore SIGINT?
> 
> > Similarly, if a program uses sigwait to wait for SIGINT, and the
> > program receives a SIGINT, the SIGINT is _not_ intercepted by ptrace,
> > it goes straight to the inferior.
> 
> This sounds like a more serious issue, but how many programs use this
> technique?
> 
> I guess what I'm asking is whether these issues really justify the
> complications of setting up a separate terminal.  The fact that the
> inferior could be stopped by a different signal, the fact that it
> could be hit by SIGHUP, the fact that users will need to decide
> whether or not they use the separate-terminal method (which will be
> the default, a backward-incompatible change) -- are all these
> complications really worth the (IMO) minor issues they solve?
> 
> Thanks.
>