Re: [PATCH] Unconditional quit on SIGUSR2

[Daniel Colascione]

On 3/28/11 4:48 AM, Eli Zaretskii wrote:
>> 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?

Killing Emacs destroys any transient state. The last-resort-quit
approach doesn't.  Attaching a debugger is well and good, but one isn't
always available, and even if one is, symbols for Emacs aren't always on
the system, as is the case for a typical Emacs distribution package.

Providing this facility (which does nothing unless you use it) can let
users recover work and provide more detailed bug reports, as well as
help us ferret out the cause of hard-to-reproduce lockups in font-lock
code without having to run under a debugger all the time.

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

Of course we can't quit just anywhere.  All the king's horses and all
the king's men couldn't safely break Emacs out of arbitrary C code ---
but we don't have to: the idea is to be able to quit in reasonable
places, e.g. where could insert a (debug) in Lisp.  This way, we can
hope to interrupt runaway font-lock code, and for this application, my
proposed approach does indeed work.  If I could have implemented this
feature without introducing additional machinery, I would have.

If you're modifying the core redisplay code and introduce a hang, you
probably have a debugger available.  OTOH, it's perfectly reasonable to
tweak font-lock code without one.

I've attached a new version of my patch that changes the action name
from "quit" to "debug" instead of "quit" to reflect what we actually do.
 I've also made the code attempt to regain control in another way.  This
version successfully breaks out of font-lock code running during
redisplay when C-g does not.

debugsig.patch
Description: Text document

signature.asc
Description: OpenPGP digital signature