|
From: | Lennart Borgman (gmail) |
Subject: | Re: Emacs does not listen on w32 |
Date: | Mon, 14 Apr 2008 22:37:51 +0200 |
User-agent: | Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.9) Gecko/20071031 Thunderbird/2.0.0.9 Mnenhy/0.7.5.666 |
Jason Rumney wrote:
Stefan Monnier wrote:If you have such an infinite loop within a timer code, then Emacs *is* hung, and it seems perfectly fine to let the OS's IsHungAppWindow deal with it.I think Lennart's problem is that we don't let the OS's IsHungAppWindow deal with it. In Windows, each Window must have its own thread for message handling. This thread is not blocked by the infinite loop in the Lisp thread, so as far as Windows is concerned, the message has been received and dealt with. We could change the WM_CLOSE message to do a blocking SendMessage instead of a non-blocking PostMessage to pass the message on to the Lisp thread, but if we decide that the solution we want is to let Emacs be forcibly closed after a timeout, it might be better to have our own timeout so we can control what message we display to the user and at least attempt to quit the Lisp blockage and shutdown cleanly rather than letting the system do it uncleanly.
I do not understand what you mean here. Does the lisp thread look for new messages when it is looping? (I think it should.)
If it does then shouldn't it find a message from PostMessage?If it does not then we can't do any useful after a SendMessage with timeout either, or can we?
[Prev in Thread] | Current Thread | [Next in Thread] |