[python-win32] Is it possible to pump messages in thread?

[Richard Bell]

Mark,

Thanks very much for your assistance.  Based on my rather limited experience
and understanding of com I'm still a bit uncertain but if I understand your
comments correctly what I've done in the free-threaded test is sound and
should work reliably.  This is a serious concern for me as the application
must run 24x365 if it is to replace the current version (the current version
has had only 3 unscheduled outages in 18 months ... 2 cable cuts and 1
router fire).

As to the test applications, I'll send along three to you at the mailto
address below unless you prefer I post them to the mailing list.  The first
will have a very simple PumpWaitingMessages loop and a flag for the
DocumentComplete event modeled after the existing Visible flag.  It's
relatively easy to understand and provides a more realistic example than the
current Visible test. I'll have a bit of time tomorrow AM and will clean up
the current version and send it along.  The second uses
MsgWaitForMultipleEvents (something you've mentioned in several of your
correspondences but which I was unable to find in an example).  It is useful
principally as an example of how to use the MsgWait to avoid polling.  The
third is the free-thread routine with no message pump.  I should have time
between now and next week to clean these other two up and send them along.
I'll model all three after the existing test routines (I assume they are run
as part of builds) so hopefully they can be used with minimal effort on your
part.  After you've had a chance to look at them feel free to let me know of
any changes that would make them more suitable for your purposes.

Regards,
Richard

|-----Original Message-----
|From: Mark Hammond [mailto:mhammond at skippinet.com.au]
|Sent: Tuesday, February 07, 2006 6:23 PM
|To: Richard Bell; python-win32 at python.org
|Subject: RE: [python-win32] Is it possible to pump messages in thread?
|
|> Thanks, that clears things up a bit (I'm new to com and my
|> understanding is
|> rather tenuous) and I think I understand why this does not work.
|> The net of
|> what I think you are saying is that as a practical matter message running
|> the message pump in a thread has little effect since the messages proper
|> (and events) will be delivered to the main thread.
|
|Actually, the pump in the other thread is likely to be necessary so that
|the
|marshalling between threads can occur correctly.  The upshot is that you
|probably can not get the events to fire on the other thread, when the
|object
|was not created in the free-threaded apartment.
|
|> Unfortunately, as a general rule for my purposes it is not practicable to
|> have the main thread spin the message loop.  The underlying reason is
|that
|> the application generally has no pre-knowledge of the nature of the web
|> pages and the pages script.  Absent such knowledge, the
|> application does not
|> know if the message loop needs to be spun from time to time.
|
|Its not the "main" thread as we usually think of it.  The issue is the "COM
|Object's thread".  It should be fine to spin a new thread, create the
|object
|on that thread.  It might not be necessary to run a message loop on that
|thread, as no marshalling is required in that case (ie, all operations
|happen on the object's "main" thread)
|
|> I'm a bit unclear on this comment:
|>
|> |The reason is that IE itself is not fully
|> |free-threaded, so events etc will be delivered to the IE "main
|> thread", not
|> |to the thread it is being currently used from
|>
|> Isn't IE running in a separate process?  If that is true aren't
|> IE's events
|> delivered back to my application via COM so that my threading
|> model would be
|> largely independent from whatever IE is doing (contingent on whatever
|> python-com does)?
|
|Right - yes, that is correct.  The cross-process marshalling COM uses will
|take care of these threading issues, so the object is not restricted in the
|same way it would be in-process.
|
|> On the assumption that this might be true, I
|> modified my
|> application per the example in appendix D by:
|>
|> --- begin python code ---
|> import sys
|> sys.coinit_flags=0          # specify free threading
|> import pythoncom
|> --- end python code ---
|>
|> A bit of experimentation suggests that it is not now necessary to run the
|> message pump at all.  Interestingly, when I modify the event debug print
|I
|> find that events are being processed on one of two threads
|> neither of which
|> is my main thread.  I'm a bit unclear as to why this is so but it is.  I
|> assume that somewhere within pythoncom messages are being pumped.
|
|You have created a "free threaded" COM object - which as above, works fine
|as the object is in another process (and the cross-process marshaller will
|take care of what happens in that other process).
|
|As a result, *no* thread marshalling happens in the Python process, and you
|can freely pass pointers unmarshalled between free-threaded threads.  The
|message loop is only needed for this marshalling to work - but as there is
|none, no message loop is necessary.
|
|> From the point of view of my test application, all appears well
|> but since I
|> don't really understand what is happening (within pythoncom I
|> guess) or what
|> your remark concerning IE free-thread really means I'm a bit
|> concerned.  Can
|> you provide any insight concerning pythoncom's role in this matter
|> particularly relative to DispatchWithEvents and messages in a free-thread
|> apartment?
|
|Yes, thanks for pointing out my error - I hope the above explains things
|more satisfactorily.
|
|> By way of thanks for your help I'll gladly contribute my test
|> application to
|> the test suite.  I evolved it off of TestExplorer.py which works but is
|> somewhat misleading concerning event handling (OnVisible is one
|> of the very
|> few events that can be caught in the fashion used by the current test).
|> Perhaps others would find some benefit as I now have modified
|> tests for both
|> an active PumpWaitingMessages off of an event and a free-thread version
|> (appears to work but I clearly do not really understand why).
|
|That would be great!
|
|Mark