bug#9087: Crash reading from minibuffer with icomplete-mode

[Eli Zaretskii <eliz@gnu.org>]

> Date: Sat, 07 Jan 2012 11:11:57 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: Stefan Monnier <monnier@iro.umontreal.ca>, 
>  Jason Rumney <jasonr@gnu.org>,
>  claudio.bley@gmail.com, lekktu@gmail.com, 9087@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.