GNU bug report logs -
#9087
Crash reading from minibuffer with icomplete-mode
Previous Next
Full log
Message #137 received at 9087 <at> debbugs.gnu.org (full text, mbox):
> Date: Sat, 07 Jan 2012 11:11:57 +0100
> From: martin rudalics <rudalics <at> gmx.at>
> CC: Stefan Monnier <monnier <at> iro.umontreal.ca>,
> Jason Rumney <jasonr <at> gnu.org>,
> claudio.bley <at> gmail.com, lekktu <at> gmail.com, 9087 <at> debbugs.gnu.org
>
> >> Is a C-g also delayed in a similar way under w32?
> >
> > Yes, it is, at least in this case.
>
> Can you please explain what this means? If C-g is delayed does it mean
> that I can't use it to quit immediately? Or does it mean that I can
> crash Emacs via C-g in a similar way as with the OP's scenario?
The former, of course. You can verify yourself that, in Emacs without
the patch I sent, typing C-g when triggerbug.el says "now!" does not
cause a crash, but a "Quit", albeit a slightly (by 1-2 seconds on my
box) delayed one.
> Why and how is all this handled differently on GNU systems?
On Posix hosts, Emacs reads keyboard input in the main thread, where
it is possible to do a throw to top level without wreaking havoc on
the stack. In some configurations, keyboard input is actually handled
in a signal handler, and then the throw is even faster, because it
interrupts any on-going operation.
On Windows, there's a separate thread that reads messages posted by
Windows to the Emacs windows. Throwing to top level from a different
thread is a no-no. With my patch, throwing will be deferred until the
main thread is done with whatever it is doing, and gets to reading
input.
This bug report was last modified 13 years and 127 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.