event loop problem

[Alex Martelli]

"Geoff Talvola" <gtalvola at nameconnector.com> wrote in message
news:mailman.972333065.14276.python-list at python.org...
> I know exactly the problem you're talking about -- and I consider it a
huge
> design flaw in NT that any one application can cause other applications to
> hang if it's not processing its message loop.

Only if those "other applications" *WANT* to hang; otherwise,
they would be using SendMessageTimeout (to guarantee termination
by time-out if needed) rather than SendMessage (whose semantics
are blocking, without a timeout, like those of many other system
calls).

Do you consider it "a huge design flaw in Unix that any one
application can cause other applications to hang" if it's not
serving its end of a socket -- IF, that is, those other
applications use blocking syscalls on that socket rather
than select-with-timeout, &c...?-)

Blame it on the laziness of people using SendMessage with
broadcast-destination... I can see no justification for it,
ever, except the historical accident that SendMessageTimeout
was not available on 16-bit Windows lo those many years ago.

Generally, the big culprit is the library DDEML, which WAS
written at the time of 16-bit Windows and MS has been yearning
to kill -- with all DDE variants -- even since they introduced
COM as a vastly superior alternative for inter-application
communications; *that* one, internally, uses just such a
silly SendMessage -- the bug has been known and documented
for many years, and it's never going to get fixed.  Solution:
eschew DDE.  Alternate solution: if you MUST do DDE at all
cost, eschew DDEML, doing low-level DDE programming instead,
so you can have a timeout on all the messages you send!-).

A good FAQ on DDE is at:
http://www.angelfire.com/biz/rhaminisys/ddeinfo.html
and its author doesn't necessarily agree with me (he likes DDE
for many tasks, I detest it heartily:-), but he has good
points & good info in there, anyway.

> Starting up PythonWin is
> another example of something you can't do if any program isn't processing
> its messages.

Really?  I hadn't noticed.  This is a bug in PythonWin, from
my POW -- it should NOT be doing a broadcast SendMessage without
a timeout (be it via DDEML or otherwise).  Have you submitted
this bug to ActiveState?


> But a better solution is to tell win32com to run in free-threading mode,
in
> which case it doesn't create a hidden window and everything works fine

No, but it DOES freely create threads!  Remember to protect
all access to shared-data if you choose this route.  Personally,
I think serving the message-loop is simpler.


Alex