|
From: | Daniel Colascione |
Subject: | Re: [PATCH] Unconditional quit on SIGUSR2 |
Date: | Mon, 28 Mar 2011 12:49:53 -0700 |
User-agent: | Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 |
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.
[Prev in Thread] | Current Thread | [Next in Thread] |