From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Jason Rumney Newsgroups: gmane.emacs.devel Subject: Re: Emacs does not listen on w32 Date: Mon, 14 Apr 2008 20:55:17 +0100 Message-ID: <4803B6A5.4030201@gnu.org> References: <4800D965.9080202@gmail.com> <480208C8.3030401@gnu.org> <480212F7.7090409@gmail.com> <4802249D.2060909@gmail.com> <480271D2.7040304@gmail.com> <4802FD64.1080602@gmail.com> <48038487.3060201@gmail.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1208203185 28398 80.91.229.12 (14 Apr 2008 19:59:45 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 14 Apr 2008 19:59:45 +0000 (UTC) Cc: Juanma Barranquero , Eli Zaretskii , "Lennart Borgman \(gmail\)" , emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Apr 14 22:00:19 2008 connect(): Connection refused Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1JlUmy-0005y2-Hw for ged-emacs-devel@m.gmane.org; Mon, 14 Apr 2008 21:56:28 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JlUmK-0005fK-5K for ged-emacs-devel@m.gmane.org; Mon, 14 Apr 2008 15:55:48 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JlUmG-0005fB-9N for emacs-devel@gnu.org; Mon, 14 Apr 2008 15:55:44 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JlUmE-0005ey-Ps for emacs-devel@gnu.org; Mon, 14 Apr 2008 15:55:43 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JlUmE-0005ev-L7 for emacs-devel@gnu.org; Mon, 14 Apr 2008 15:55:42 -0400 Original-Received: from mk-outboundfilter-3.mail.uk.tiscali.com ([212.74.114.23]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1JlUm9-00037B-Rw; Mon, 14 Apr 2008 15:55:38 -0400 Original-X-Trace: 95453486/mk-outboundfilter-1.mail.uk.tiscali.com/F2S/$ACCEPTED/freedom2Surf-customers/83.67.23.108 X-SBRS: None X-RemoteIP: 83.67.23.108 X-IP-MAIL-FROM: jasonr@gnu.org X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Al0FAPxSA0hTQxds/2dsb2JhbACBXqla X-IP-Direction: IN Original-Received: from i-83-67-23-108.freedom2surf.net (HELO wanchan.jasonrumney.net) ([83.67.23.108]) by smtp.f2s.tiscali.co.uk with ESMTP; 14 Apr 2008 20:55:36 +0100 Original-Received: from [192.168.249.27] (chiko.jasonrumney.net [192.168.249.27]) by wanchan.jasonrumney.net (Postfix) with ESMTP id 0E00549; Mon, 14 Apr 2008 20:55:39 +0100 (BST) User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) In-Reply-To: X-Enigmail-Version: 0.95.6 OpenPGP: id=8086879D X-detected-kernel: by monty-python.gnu.org: Genre and OS details not recognized. X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:95206 Archived-At: 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.