Re: [PATCH] Unconditional quit on SIGUSR2

[Eli Zaretskii]

> Date: Mon, 28 Mar 2011 00:14:22 -0700
> From: Daniel Colascione <address@hidden>
> 
> Sometimes Emacs gets stuck in places where quitting is suppressed,
> such as during redisplay.  For most users, the only way to deal with
> this situation is to abruptly terminate Emacs.
> 
> This patch allows users to recover from this situation by sending Emacs
> a SIGUSR2 signal.  When we receive it, we set debug-on-quit to t,
> inhibit-quit to nil, and quit-flag to t.  These operations will force
> Emacs to stop at the next possible opportunity and display a backtrace.
>  From here, users can save their work, and developers can figure out
> what caused the hang.

If the goal is to provide a way for the user to interrupt a stuck
Emacs in a way that allows to save edits or debug Emacs, then users
can already send SIGTERM and developers can already attach a debugger,
and that will achieve the same result.  Why do we need a new machinery
to do something that is already possible via essentially the same
sequence of actions, i.e. type "kill EMACS-PID" at the shell prompt?

Or am I missing something?

Btw, did you actually test the possibility to interrupt a stuck
redisplay using this patch?  I'm asking because I think redisplay
cannot be interrupted like that: it never checks the quit flag, and
for a good reason AFAIK -- you cannot interrupt it at an arbitrary
point without disastrous consequences.  If we want to make redisplay
interruptible, we need to add code to it in strategic places.  Again,
I don't see a need for doing this, unless someone shows a convincing
use case where such a feature would be useful.

Apologies if I missed something obvious, and thanks for working on
this.