event loop problem

[Geoff Talvola]

Alex Martelli wrote:

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

The problem I have is that any one application that is *completely* *unrelated*
to another application can nevertheless cause that other application to hang by
not processing its message loop.  From what you're saying, it's a bug in those
applications, not in Windows -- I can accept that.  However, it's not exactly
obvious when you have accidentally created a hidden window and therefore need to
be processing messages.  I use Spy++ from Visual Studio to diagnose these
things, but usually I don't realize I've created a hidden window until I start
noticing things like PythonWin not starting up :-)

> [snip]
> > 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?

I didn't know it *was* a bug, since I've seen so many other programs behave the
same way :-)

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

For a single-threaded Python program using ADO, there's no shared data to worry
about.  And what if your program structure contains long-running calculations
based on data from your ADO database?  You have to contort your calculations to
insert PumpWaitingMessages() calls everywhere.  A single-threaded, non-GUI
application shouldn't have to have a message loop, IMO.

In my experience, whether or not you're using free-threading mode, ADO will
create lots of threads and a hidden window for its own use anyway.  The
difference is that in free-threading mode, the hidden window is in a different
thread and appears to have its messages processed automatically, whereas if you
use the default single-threaded apartment, the hidden window is created in the
main thread and you have to explicitly use PumpWaitingMessages everywhere.

--


- Geoff Talvola
  Parlance Corporation
  gtalvola at NameConnector.com