unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Benjamin Riefenstahl <Benjamin.Riefenstahl@epost.de>
Cc: Dhruva Krishnamurthy <devel@member.fsf.org>,
	Emacs Devel <emacs-devel@gnu.org>
Subject: Re: addpm.c: DdeConnect() without timeout
Date: Mon, 03 May 2004 16:51:50 +0200	[thread overview]
Message-ID: <m3zn8py35l.fsf@seneca.benny.turtle-trading.net> (raw)
In-Reply-To: <ur7u1aix0.fsf@jasonrumney.net> (Jason Rumney's message of "03 May 2004 11:45:15 +0100")

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

      parent reply	other threads:[~2004-05-03 14:51 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-05-03  6:07 addpm.c: DdeConnect() without timeout Dhruva Krishnamurthy
2004-05-03 10:45 ` Jason Rumney
2004-05-03 11:28   ` gmake info: makefile patch Dhruva Krishnamurthy
2004-05-03 11:35   ` addpm.c: DdeConnect() without timeout Dhruva Krishnamurthy
2004-05-03 14:51   ` Benjamin Riefenstahl [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=m3zn8py35l.fsf@seneca.benny.turtle-trading.net \
    --to=benjamin.riefenstahl@epost.de \
    --cc=devel@member.fsf.org \
    --cc=emacs-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).