Re: Interrupting computations using signals

[Eli Zaretskii <eliz@gnu.org>]

> Cc: emacs-devel@gnu.org
> From: Daniel Mendler <mail@daniel-mendler.de>
> Date: Mon, 24 May 2021 16:08:07 +0200
> 
> I have a file "interrupt.el" containing this code:
> 
> ~~~
> (defun sigusr-handler ()
>   (interactive)
>   (message "Caught signal %S" last-input-event))
> 
> (define-key special-event-map [sigusr1] 'sigusr-handler)
> (define-key special-event-map [sigusr2] 'sigusr-handler)
> 
> (condition-case nil
>     (while t
>       (with-local-quit
>         (while t
>           (sleep-for 0.1)))
>       (message "QUIT"))
>   (t (message "OUTER QUIT")))
> ~~~
> 
> 1. I start the batch process with "emacs -Q --batch -l interrupt.el" or
> "emacs -Q --fg-daemon -l interrupt.el".
> 
> 2. I send a SIGUSR1 signal to the process. The signal is ignored.
> Nothing happens, in particular the handler is not called.
> 
> 3. I send a SIGUSR2 signal to the process. The process terminates with
> the message "Debugger entered--beginning evaluation of function call
> form: * (setq quit-flag t)...". I neither see the "QUIT" nor the "OUTER
> QUIT" message.

See the documentation of debug-on-event to understand the effect of
SIGUSR2.

As for the effect of SIGUSR1, I think that at least part of the issue
is that you never give Emacs the chance to read the sigusr1 "key".  As
you see from the example in the ELisp manual that you copied, this
feature works by generating an input event, but if Emacs doesn't read
input, it will never pay attention.

I guess this is where you tell more about your use case, so that we
could understand why, for example, what SIGUSR2 does is not what you
wanted.