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

unarchive 202

From: "Dhruva Krishnamurthy" <devel <at> member.fsf.org>
To: "Emacs Devel" <emacs-devel <at> gnu.org>
Subject: addpm.c: DdeConnect() without timeout
Date: Mon, 03 May 2004 11:37:15 +0530

Hello,
 I had reported a problem with addpm.exe on W2K. I am building CVS HEAD
 using MinGW-GCC and MSVC6 and face the same problem of addpm.exe getting
 stuck duing "nmake (gmake) install".
I found that it is getting stuck in DdeConnect(). I am not aware of DDE
mechanism but feel we should have a time out. Since "addpm.exe" is trivia
and does not affect the working of GNU Emacs, the install should progress
even if "addpm.exe" fails.

 Also, I noticed "gmake info" failes on MinGW-GCC on W2K. The problem is
 with backslash ("\") in makefile.w32-in at target "info:". Changing it
 to forward slashes "/", fixes this problem.

with best regards,
dhruva
________________________________________
Dhruva Krishnamurthy
Proud FSF member: #1935
http://schemer.fateback.com/

_______________________________________________
Emacs-devel mailing list
Emacs-devel <at> gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

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: Re: 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

From: Jason Rumney <jasonr <at> gnu.org>
To: 202-done <at> debbugs.gnu.org
Subject: bug#202: addpm.c: DdeConnect() without timeout
Date: Thu, 15 Jan 2009 23:10:36 +0800

I decided to fix this by creating the Shortcuts using the Shell API 
where possible, only falling back on the deprecated DDE ProgMan 
interface when that fails (which should only happen on copies of Windows 
95 and NT 4.0 that have not been updated since 1996).

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

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