Re: [PATCH] Unconditional quit on SIGUSR2

[Daniel Colascione]

On 3/28/2011 12:41 PM, Eli Zaretskii wrote:
> 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.

My patch does not do the same thing.  Instead, my patch returns the user 
to an *interactive* context where he can continue using Emacs normally 
after resolving whatever was causing the infinite loop (perhaps by 
closing a buffer, or setting some configuration variables).  It is not 
an unconditional quit the same way SIGTERM is.

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

It would solve that problem but introduce another: users have no way of 
knowing went font-lock happens.  Innocently typing C-g at the wrong time 
can terminate font lock and leave parts of the buffer unfontified.  It's 
inherently racy.  We need an alternate mechanism that is not as easy to 
trigger.  Signals provide such a mechanism.