Home Original page

Multithreaded COM server problem...

Mark Hammond mhammond at skippinet.com.au
Thu Jan 15 21:07:30 EST 2004 
John Lull wrote:
> Mark Hammond <mhammond at skippinet.com.au> wrote (with possible
> deletions):
> 
> 
>>John Lull wrote:
> 
> ...
> 
>>>Unfortunately, this one has to be a local server since it's providing shared
>>>access to a pool of hardware devices from multiple distributed clients. I've
>>>carefully reviewed chapters 5 & 12, and appendix D, and wasn't able to find
>>>anything addressing threading models in the local server in detail. If I've
>>>missed something, I'd be grateful for any additional hints. 
>>
>>The problem is that your client code is not running a message loop.  If 
>>you change the loop of your client test code to something like:
>>
>>for i in range(delay)*10:
>>     time.sleep(0.1)
>>     pythoncom.PumpWaitingMessages()
>>
>>It works as you expect.  A better choice would probably be 
>>win32event.MsgWaitForMultipleObjects, but that depends on what your app 
>>really does.
>>
>>Mark.
> 
> 
> I presume you meant my server code. 

Nope - I meant the client.  The server is already running such a loop 
thank to localserver.py, which is hosting the object.

The client code's main (and only) thread is blocked in a system call, 
but it appears COM wants it to pump messages so the marshalling magic 
happens.  I can only speculate why COM needs this to happen in this 
trivial case, but COM's rules do state this requirement.

> This still leaves all calls to the
> server running in a single thread, however. If I insert a call to
> PumpWaitingMessages() in a short operation, and it happens to start a
> long operation, the result of that short operation will be delayed
> until the long operation completes. This will make my server unusable.

Make the change I suggested, and it works as you hope.

> At first glance this seems to do what I want -- requests to the server
> seem to run from a thread pool. However, I also get intermittent (but
> frequest) startup errors, with a Microsoft Visual C++ Runtime Library
> error dialog (during pythoncom.PumpMessages but before my server
> module gets imported) reporting:
>   Runtime Error!
>   Program: c:\Apps\Python2.2\pythonw.exe
>   abnormal program termination

That sucks, and is almost certainly a thread-state error.  If you have a 
debug build of Python, it will offer to break into the debugger at this 
point.

Mark.
More information about the Python-list mailing list