Re: [PATCH] Unconditional quit on SIGUSR2

[Daniel Colascione <dan.colascione@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 4484 bytes --]

On 3/28/11 7:47 AM, Eli Zaretskii wrote:
>> Date: Mon, 28 Mar 2011 06:38:39 -0700
>> From: Daniel Colascione <dan.colascione@gmail.com>
>> CC: emacs-devel@gnu.org
>>
>>> 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?

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.  All that
can be recreated, but losing this state and having to recreate it  is
very inconvenient.

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

Even "illegible byte codes" can be quite useful for narrowing the
problem down to the function level, and getting a detailed traceback
from a reproducible hang could be a matter of find-function and
eval-buffer --- steps that, if need be, can be taken by uninitiated
users without the installation of a debugger.

(Speaking of debugging bytecode, by the way: would it be feasible to
someday provide the ability to step through compiled functions
bytecode-by-bytecode?)

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

Sure --- I'm merely pointing out that the feature does nothing *at
runtime* unless used.

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

Auto-save doesn't run continuously, and not everyone has it turned on.

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

I've long wished with-timeout would put a hard limit on execution time
(to within QUIT granularity).  This hard timeout capability would
provide a way to automatically cancel runaway fontification.  On the
other hand, this feature would be difficult to implement,
platform-dependent, and not applicable to more general cases.  How long
is "too long"?

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

What Lisp-level method do you propose for breaking out of (let
((inhibit-quit t)) (while t)) ?  ISTR a proposal that would have C-g C-g
C-g ignore inhibit-quit, but this approach would still allow a user
leaning on C-g to cancel legitimate background work.  AIUI, this problem
was the reason quit was disabled during fontification in the first
place.  A signal doesn't confuse the issue.

I agree that it'd be better to provide a portable way to break, but a
signal is a simple and relatively portable mechanism that doesn't depend
on the IO loop.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]