GNU bug report logs - #202
addpm.c: DdeConnect() without timeout

Previous Next

Full log

View this message in rfc822 format

From: Benjamin Riefenstahl <Benjamin.Riefenstahl <at> epost.de>
To: Jason Rumney <jasonr <at> gnu.org>
Cc: "Dhruva Krishnamurthy" <devel <at> member.fsf.org>,
        Emacs Devel <emacs-devel <at> gnu.org>
Subject: bug#202: addpm.c: DdeConnect() without timeout
Date: Mon, 03 May 2004 16:51:50 +0200

Hi Jason, all,


> "Dhruva Krishnamurthy" <devel <at> member.fsf.org> 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 <jasonr <at> gnu.org> 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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.