addpm.c: DdeConnect() without timeout

addpm.c: DdeConnect() without timeout

[Dhruva Krishnamurthy]

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/

Re: addpm.c: DdeConnect() without timeout

[Jason Rumney]

"Dhruva Krishnamurthy" <devel@member.fsf.org> writes:

> 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.

If you can find where in the addpm code it is failing, we can catch
whatever problem it is and do something appropriate.

Could it be due to access rights to the Start Menu or registry?

>  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.

nmake seems to accept either, so I've installed this fix.

gmake info: makefile patch

[Dhruva Krishnamurthy]

> >  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.
> 
> nmake seems to accept either, so I've installed this fix.

It has to be done in emacs/nt/makefile.w32-in file (not in
man/makefile.w32-in). Sorry for not being more specific.

-dhruva

Diff for original versus modified [diff -p
\tmp\cvs\emacs\nt\makefile.w32-in makefile.w32-in]

*** \tmp\cvs\emacs\nt\makefile.w32-in   Fri Apr 23 09:16:57 2004
--- makefile.w32-in     Mon May  3 12:59:23 2004
*************** force-info:
*** 218,226 ****
  # put the info files in $(infodir),
  # so we can do ok running make in the build dir.
  info: force-info
!       (cd ..\man && $(MAKE) $(MFLAGS) info)
!       (cd ..\lispref && $(MAKE) $(MFLAGS) info)
!       (cd ..\lispintro && $(MAKE) $(MFLAGS) info)

  #
  # Maintenance
--- 218,226 ----
  # put the info files in $(infodir),
  # so we can do ok running make in the build dir.
  info: force-info
!       (cd ../man && $(MAKE) $(MFLAGS) info)
!       (cd ../lispref && $(MAKE) $(MFLAGS) info)
!       (cd ../lispintro && $(MAKE) $(MFLAGS) info)

  #
  # Maintenance
________________________________________
Dhruva Krishnamurthy
Proud FSF member: #1935
http://schemer.fateback.com/

Re: addpm.c: DdeConnect() without timeout

[Dhruva Krishnamurthy]

On Mon, 03 May 2004 06:45:15 +0000, "Jason Rumney" <jasonr@gnu.org> said:
> "Dhruva Krishnamurthy" <devel@member.fsf.org> writes:

> > 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.

> If you can find where in the addpm code it is failing, we can catch
> whatever problem it is and do something appropriate.
>
> Could it be due to access rights to the Start Menu or registry?

I think it was due to some registry corruption, I am not sure of what
though. I ran a registry cleaning utility. I am now able to run
"addpm.exe" and it works as it used to earlier. So, there is no problem.
However, this is the second time I am facing this problem and I feel we
should have a time out mechanism if supported by DdeConnect(). There is 1
call to DdeConnect() in addpm.c at line:184. It gets stuck there when I
faced the problem. Calls to DdeInitialize() returns a successfull code.
It might be a good idea to check that too to make it a little more
robust.
Ex: 
if(DMLERR_NO_ERROR!=DdeInitialize())
  return(1); // Some non zero error value

-dhruva
________________________________________
Dhruva Krishnamurthy
Proud FSF member: #1935
http://schemer.fateback.com/

Re: addpm.c: DdeConnect() without timeout

[Benjamin Riefenstahl]

Hi Jason, all,


> "Dhruva Krishnamurthy" <devel@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@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