Re: [PATCH] Unconditional quit on SIGUSR2

[Daniel Colascione]

On 3/28/2011 11:37 AM, Eli Zaretskii wrote:
> > > > Killing Emacs destroys any transient state. The last-resort-quit
> > > > approach doesn't.
> > > You originally said "save edits or debug Emacs", see above.
> > >
> > > What transient state are we talking about?
> > I'm talking about any state not already written out to more permanent
> > storage --- that includes not only unsaved buffer contents, but tramp
> > sessions, window configurations, various histories, and so on.
> Isn't that part of handling a fatal signal?

Right --- but with a patch like mine, a lockup in font-lock or some 
other obscure corner of the codebase isn't fatal anymore.

> > (Speaking of debugging bytecode, by the way: would it be feasible to
> > someday provide the ability to step through compiled functions
> > bytecode-by-bytecode?)
> I'm not sure I understand what you are suggesting here.  What I would
> love is the ability to "disassemble" a Lisp backtrace, so that any
> byte codes are converted into human-readable Lisp (or something
> similar).  Perhaps there's already such a thing, who knows?

There isn't, to my knowledge.  What I'd like to see is the ability to 
view and step through Emacs disassembled bytecode the same way we can 
view and step through disassembled machine code in gdb.  I don't know 
how  complex the implementation of such a feature would be, but we do 
have a disassembled in Emacs to start.

> > > > 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'd like to hear what work can be recovered this way that is not
> > > recovered by auto-save at fatal signal time.
> > Auto-save doesn't run continuously, and not everyone has it turned on.
> I meant the automatic auto-save triggered by catching a fatal signal.
> See emacs.c:fatal_error_signal.

Ah, I didn't know about that.  It'd still be nice to be able to recover 
a hung Emacs process instead of killing it, and my point about having to 
restore other transient state still applies.

> > What Lisp-level method do you propose for breaking out of (let
> > ((inhibit-quit t)) (while t)) ?
> This isn't an interesting example.  I was talking about font-lock,
> which I understand was the primary motivation for this patch.
> Font-lock does not have such useless loops (I hope ;-).

It shouldn't, but there are and always will be bugs that result in 
essentially identical behavior.

> I was asking about whatever you had in mind when you wished you could
> implement such a feature without introducing additional machinery.
> You tell me.

We want to be able to interrupt code running in a tight loop in 
situations when quit would normally be disabled, such as during 
redisplay.  Quit is disabled during background work for a good reason, 
so we shouldn't just rely on the normal quit mechanism.  Thus, we need 
some other way of signaling Emacs.  If events aren't being delivered, as 
in a tight loop, then commands won't be run and anything bound normally 
to some keymap will be useless.  One way of delivering an event to Emacs 
that does not depend on the command loop is the signal mechanism.  There 
is a facility to bind a command to a signal via `special-event-map'.  
This facility is not useful for our purposes here because it works by 
having signals post events to the command loop, which, as we've already 
established, is not running.  Except for the quit mechanism itself, 
there is no way to configure Emacs to react asynchronously to some event 
when the command loop will not run, and so there is no way to break into 
a wedged Emacs.  Any implementation of this functionality will require 
changes to the C core.

We have a few options for the implementation strategy:

1) Bind (debug) to a signal in special-event-map, and send Emacs that 
signal to interrupt it.  We would have to change the core such that it 
would run commands associated with pending signals during QUIT.

2) Create a quit-like mechanism in all the ports that would listen for a 
special character.  This character would be interpreted like C-g today, 
except that it would unconditionally break into the debugger.

3) Provide an explicit way to configure the C core to break in response 
to a signal, then send that signal to interrupt Emacs.  This is the 
approach I've implemented.

Option 1 wont work because code today doesn't expect to arbitrary Lisp 
code to run wherever there is a QUIT, and running a command implies just 
that.  Option 2 is more invasive, steals a key, and doesn't add any 
expressive power.  I've implemented option 3, and it works well enough 
so far.