Re: [PATCH] Unconditional quit on SIGUSR2

[Eli Zaretskii <eliz@gnu.org>]

> Date: Mon, 28 Mar 2011 12:29:29 -0700
> From: Daniel Colascione <dan.colascione@gmail.com>
> CC: emacs-devel@gnu.org
> 
> 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.

We are miscommunicating: I meant that delivering a SIGTERM will end up
in fatal_error_signal, which will save all that's worth saving, before
Emacs commits suicide.  Your patch achieves the same goal, as far as
saving unsaved work is concerned, except it uses SIGUSR2.

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

If it is safe to interrupt font-lock with the method used by your
patch, it should be safe to enable quitting when redisplay calls
font-lock, right?  So maybe we should simply enable quite when
redisplay calls font-lock and disable it when font-lock returns back
to redisplay code which called it.  Then C-g will be able to interrupt
it.  Would that solve the problem with font-lock that gets stuck?