event loop problem

Geoff Talvola gtalvola at nameconnector.com
Tue Oct 24 14:13:59 EDT 2000


Alex Martelli wrote:

> > > > 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
>
> If that Python program exposes COM stuff, and it tells COM it's free
> threaded, it's a risky gamble to call it "single-threaded".  _IT_ does
> not explicitly start up more threads, BUT its code may be executed on
> other threads (e.g. in response to COM events, if it hooks any).  And
> I don't think the Python-interpreter's single global lock will save
> your skin in that case -- the interaction level made "atomic" by that
> lock is the single-Python-bytecode-instruction, which I think is too
> semantically low (which is why Python multithreaded programs use their
> own locking strategies).

Interesting... I hadn't considered that COM events could be executed on a
different thread in free threading mode.  I don't happen to be hooking any COM
events at the moment though.

> > 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.
>
> I disagree.  _Particularly_ if that application "contains long-running
> calculations", it *should* be checkpointing regularly, *and* responding
> sensibly when the system tells it "we're about to go down, is that
> all right?" -- which it does by sending it appropriate messages.  It's
> even more important when the system has advanced power management: if
> the application doesn't handle that, it has no way to tell the system
> "no, DON'T switch to low-power-mode, I need all the CPU I can get for
> my long-running calculations!", etc, etc.

You're right, these are certainly valid concerns for many (but not all) apps.

> I'll freely admit I have not looked at the issue of ADO "creating lots of
> threads", and I do wonder where that extra 'hidden window' comes from (are
> there apartment-threaded objects in the ADO/OleDb internals, not just
> free-threaded ones...?).  But I wonder how you _ensure_ that none of your
> code is ever executed on one of those other "lots of threads" -- maybe
> by exposing no COM functionality whatsoever, including not hooking any
> events.  Seems a rather high price to pay, in general, though it may be
> OK for a lite/throw-away little thingy that doesn't need to receive
> events or be externally-automatable anyway.

Here's my reasoning for choosing free threading in my app (which is certainly
not a lite or throwaway thingy):  My app is a web application built around a
multithreaded web application server (WebKit, part of WebWare for Python) which
has a main thread and a number of worker threads, each of which uses ADO for
database access.  My ADO objects are never shared between threads, I'm not using
any COM events, and my app is not a COM server.  By using free threading, I
don't need to process messages in each of my worker threads.  I believe that if
I were using apartment threading, every one of my threads would need its own
message loop.

--


- Geoff Talvola
  Parlance Corporation
  gtalvola at NameConnector.com





More information about the Python-list mailing list