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

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

> 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.