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

[Mark Hammond]

> 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