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

[John Baldwin <jhb@FreeBSD.org>]

On 6/16/21 3:01 AM, Pedro Alves wrote:
> On 2021-06-15 5:41 p.m., John Baldwin wrote:
>> I do think it probably is clearer to use "stop" instead of "interrupt"
>> as you noted though since the "interrupted" term is a bit overloaded
>> and thus ambiguous.
> 
> I was just thinking of "interrupting" as in the dictionary English term for
> "stop the continuous progress of (an activity or process)."
> 
> I'll go over the manual changes and switch to use "stop" instead when it seems
> easy enough.
> 
> But note that the cat is out of the bag for many years now, and GDB and the manual
> already use "interrupt" pervasively to mean suspend/stop.  For example,
> the CLI command to stop a program is "interrupt":

Ah, oh well.  It is true that "interrupt" is a pretty general term (e.g.
for device interrupts it is not specific to any specific device, and
signals are effectively software interrupts in user mode, though many
of them are synchronous (SIGSEGV, etc.) and thus more traps/exceptions
rather than interrupts (which are usually used for asynchronous events)).

> So maybe the right thing to do is not the avoid the work "interrupt" altogether
> which seems impossible, but to clarify better what it means in the
> new "Interrupting" node.
> 
> For example, I had:
> 
>    @menu
>    * Breakpoints::                 Breakpoints, watchpoints, and catchpoints
>    * Continuing and Stepping::     Resuming execution
>   +* Interrupting::                Interrupting execution
>    * Skipping Over Functions and Files::
>                                    Skipping over functions and files
>    * Signals::                     Signals
>   @@ -6376,6 +6442,45 @@ default is @code{on}.
>    
>    @end table
>    
>   +@node Interrupting
>   +@section Interrupting
>   +
>   +You can stop the program while it is running in the foreground by
>   +pressing the interrupt character (often @kbd{Ctrl-c}).  If the program
>   +is executing in the background (@pxref{Background Execution}), you can
>   +use the @code{interrupt} command (@pxref{interrupt}).
> 
> (note how the "interrupt" command appears here)
> 
> I can see about making it clear that this interruption is mostly transparent
> to the program, other than timing issues, and maybe EINTR.  That if you want to
> affect an interrupt in the program itself, you should "signal SIGINT".

Ok, this sounds good to me.

-- 
John Baldwin