Subject: bug#6585: 23.1; Hang / CPU 100% on background interaction when in minibuffer

From: "Jason S. Cornez" <[email-masked]>
Date: Tue, 31 Aug 2010 12:34:30 +0200

Yes, I agree about fixing the elisp code - indeed this has been done.
But what about when the code isn't mine, but is in some library I happen
to be using?  Again, the right solution is always to fix the code, but
that might not be possible for the end user of emacs to do.

But I find it difficult to accept that emacs gets wedged like it does. I
love emacs and having to kill the process from the OS is just so, so
sad.  I would love a C-g C-g C-g option (just like there is ESC ESC
ESC).  And it would be even better if this could work in conjunction
with some flag so that it pops me into the debugger and I can see what
function I've broken out of.

So again, I know the elisp code was broken.  But I still say that emacs
is broken since it is currently impossible to salvage the situation.
Yes, it is a sign of a bug somewhere - and I want emacs to help me find
it, or at least escape from it.

Thanks for your consideration,
- -Jason

On 08/31/2010 12:24 PM, Stefan Monnier wrote:
>> Of course, fixing the elisp function is easy and that simply and
>> effectively avoids this problem.  Still, I find it disconcerting that I
>> can lockup emacs in such a manner.
> 
> All code run from timers and from (post|pre)-command-hook (as well as
> jit-lock, filters, and a few other things) is run with inhibit-quit set
> to t because the user may not know this code is running so if she hits
> C-g it "probably" means she wants to interrupt something else.
> 
> It's not broken.  Basically, the problem is in your code: such async
> code should not run for indefinite amount of time, whereas your code may
> inf-loop.
> 
> 2 solutions:
> - fix your code so it doesn't inf-loop (usually the best solution).
> - wrap your code in with-local-quit to let C-g interrupt it.
> 
> Admittedly, Emacs should also additionally understand something like C-g
> C-g C-g C-g as a sign that the user is getting impatient and we should
> thus ignore the inhibit-quit flag.  But such a case is always a sign of
> a bug somewhere.
> 
> 
>         Stefan