Re: [PATCH] Unconditional quit on SIGUSR2

From:

Eli Zaretskii

Subject:

Re: [PATCH] Unconditional quit on SIGUSR2

Date:

Mon, 28 Mar 2011 21:41:13 +0200

> Date: Mon, 28 Mar 2011 12:29:29 -0700
> From: Daniel Colascione <address@hidden>
> CC: address@hidden
>
> 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?