From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Benjamin Riefenstahl Newsgroups: gmane.emacs.devel Subject: Re: addpm.c: DdeConnect() without timeout Date: Mon, 03 May 2004 16:51:50 +0200 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: References: <1083564435.20498.185520391@webmail.messagingengine.com> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1083599406 2482 80.91.224.253 (3 May 2004 15:50:06 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 3 May 2004 15:50:06 +0000 (UTC) Cc: Dhruva Krishnamurthy , Emacs Devel Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Mon May 03 17:49:41 2004 Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1BKfhM-0004Wc-00 for ; Mon, 03 May 2004 17:49:40 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1BKfhM-0001zs-00 for ; Mon, 03 May 2004 17:49:40 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.30) id 1BKfak-0006EL-Lf for emacs-devel@quimby.gnus.org; Mon, 03 May 2004 11:42:50 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.30) id 1BKeoU-0001W8-Q7 for emacs-devel@gnu.org; Mon, 03 May 2004 10:52:58 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.30) id 1BKenv-0001NE-Tx for emacs-devel@gnu.org; Mon, 03 May 2004 10:52:56 -0400 Original-Received: from [193.28.100.151] (helo=mail.epost.de) by monty-python.gnu.org with esmtp (Exim 4.30) id 1BKenn-0001ML-2b; Mon, 03 May 2004 10:52:15 -0400 Original-Received: from seneca.benny.turtle-trading.net.epost.de (193.99.153.30) by mail.epost.de (6.7.015) id 40963A92000064B7; Mon, 3 May 2004 16:52:13 +0200 Original-To: Jason Rumney In-Reply-To: (Jason Rumney's message of "03 May 2004 11:45:15 +0100") User-Agent: Gnus/5.1001 (Gnus v5.10.1) Emacs/21.3.50 (gnu/linux) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:22632 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:22632 Hi Jason, all, > "Dhruva Krishnamurthy" writes: >> I found that it is getting stuck in DdeConnect(). I am not aware of >> DDE mechanism but feel we should have a time out. [...] Jason Rumney writes: > [...] > Could it be due to access rights to the Start Menu or registry? If I may put in some of my own experience with DDE here: The usual place where DDE connections block is during service discovery. The DDE mechanism will broadcast a message to find its peer and it will wait for all applications to answer. If any thread in any application has a message queue, it gets the broadcast message regardless whether it's actually doing DDE or not. Normally, even if the application doesn't handle the message itself, it will pass it on to the Windows default handler and that will do the right thing. But if the thread doesn't handle the message at all, the DDE discovery is stuck at that point. A message queue gets installed automatically, once a thread calls GetMessage() for the first time. Some applications do that only temporarily (e.g. like for a message box) and after that they never service their queue again. Curiously, the docs for MsgWaitForMultipleObjects() seem to be the only place in MSDN that actually mentions this problem. Of course that page just says, "don't do that." DDE was designed for the cooperative 16-bit Windows system where such an application would have brought the system to a complete halt anyway, so there was no propblem there. In the preemptive 32-bit Windows environment DDE is not a reliable IPC mechanism. Consequences: Use a timeout and abort the operation. I'm not sure how to do that with DDEML. Probably a separate thread would have to be used to interrupt the call to DdeConnect(). For an installation program this is probably overkill, though. From the user side, if the user runs into the problem, he can try to stop all non-essential processes and call the installation process again. benny