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

From: Eli Zaretskii <[email-masked]>
Date: Sat, 07 Jan 2012 12:49:56 +0200

> Date: Sat, 07 Jan 2012 11:11:57 +0100
> From: martin rudalics <[email-masked]>
> CC: Stefan Monnier <[email-masked]>, 
>  Jason Rumney <[email-masked]>,
>  [email-masked], [email-masked], [email-masked]
> 
>  >> 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.