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