bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Eli Zaretskii
Subject: bug#9087: Crash reading from minibuffer with icomplete-mode
Date: Sat, 07 Jan 2012 12:49:56 +0200

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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]