Re: [PATCH] Unconditional quit on SIGUSR2

[Eli Zaretskii]

> Date: Mon, 28 Mar 2011 06:38:39 -0700
> From: Daniel Colascione <address@hidden>
> CC: address@hidden
> 
> > 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.

You originally said "save edits or debug Emacs", see above.

What transient state are we talking about?

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

I very much doubt that having a Lisp level backtrace in this situation
would help.  It would typically include illegible byte codes at
crucial places.

> Providing this facility (which does nothing unless you use it)

No feature costs nothing.  At the very least, we need to document it
(thanks for doing it as part of the patch, btw), maintain it, adapt it
to future platforms and changes in existing platforms, etc.  For a
highly platform-dependent feature such as SIGUSR2, these are
non-trivial efforts whose costs should be considered against the
gains.

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

And if the main problem is with font-lock related lockups, perhaps we
should add something to font-lock to alleviate that.  That alternative
would have a benefit that it doesn't limit the solution to platforms
that support SIGUSR2.

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

What prevents the implementation on the Lisp level of a feature that
could interrupt a runaway font-lock?