Mark, I did some reading overnight and thought this through a bit more and on further consideration am concerned that the free-threaded example has a serious design flaw as follows:
When I code --- begin python code --- import sys sys.coinit_flags=0 # specify free threading import pythoncom --- end python code --- I understand that pythoncom connects to com on my behalf with a free-thread (MTA) model. If I understand correctly this means two relevant things. First, I'm asserting to pythoncom and to com that I will invoke methods on any of my com objects from threads of my choice. And second, this is the area of concern, that COM may call any event routines I provide on threads of its choice without regard to serialization. I know from testing the free-thread model that in fact the IE event routines are called on threads other than the test's main thread and that more than one thread is used to invoke the event routines (in my testing two threads). In testing so far, I've found no issues with the free-thread test case but I'm concerned that this is just an accident of good fortune since there is nothing in the design that prevents the IE event routines from being called concurrently on two different threads (absent some intervention by pythoncom to serialize the event routine calls). So long as the IE event routines do not reference any shared application data then this is not an issue. However, if the IE event routines DO reference shared application data (as they do in my real application) then it is incumbent on the event routines to insure that those references are thread safe (serialize with a lock or mutex of some sort). Is this a correct analysis? Aren't the IE event routines in a free-thread environment responsible for being thread safe? Assuming that my concerns are real, it seems to me that I can proceed on one of two courses. I can make the IE event routines thread save by serializing access to application data where appropriate or I can revisit the STA model. In thinking about this a bit more I wondered if the following STA approach would work. Create a worker thread ThreadIE. In ThreadIE pythoncomIEObject = DispatchWithEvents( ... ) so now events are serialized on ThreadIE and we are assured that we are only processing one at a time per worker thread. ThreadIE will also need to marshal pythoncomIEObject back to the main thread so that IE methods can be accessed there. Finally, ThreadIE can pump messages. Now the IE event routines running on ThreadIE still need to be thread safe relative to the main thread but at least we're only dealing with a single event at a time. As a practical matter the design of my application is such that this may be relatively easy to accomplish. Any thoughts? I'll get the first of the STA test out to you a bit later today. Richard |-----Original Message----- |From: Richard Bell [mailto:[EMAIL PROTECTED] |Sent: Tuesday, February 07, 2006 6:54 PM |To: 'Mark Hammond'; 'python-win32@python.org' |Subject: RE: [python-win32] Is it possible to pump messages in thread? | |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. | _______________________________________________ Python-win32 mailing list Python-win32@python.org http://mail.python.org/mailman/listinfo/python-win32
