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

[Pedro Alves <pedro@palves.net>]

Yes, of course, I just needed some time to think about your comments and
experiment with an idea.  I'll be replying soon.  Please don't take my silence
as ignoring you.  I'm taking you very seriously, as I always do.

On 2021-06-13 11:41 a.m., Eli Zaretskii wrote:
> 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.
>>
>