Re: Multithreaded COM server problem...

From: Mark Hammond (mhammond_at_skippinet.com.au)
Date: 01/16/04 

Date: Fri, 16 Jan 2004 13:07:30 +1100

John Lull wrote:
> Mark Hammond <mhammond@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.

Relevant Pages

  • Re: ADO data type validation is inconsistant with SS2Ks
    ... a fatal error or exception on the client and needs to be explicitly ... fails on the server, the server simply moves on to the next statement ... equivalent non-zero error code value in client code would. ... client code as possible, and send only valid data to the server. ...
    (microsoft.public.dotnet.languages.vb)
  • Re: Using SSPI in a client/server environment
    ... Are you truly saying that the client code calls AcceptSecurityContext? ... this data up and sends it to the server. ... I tried keeping the security context handle for the server and restoring it ...
    (microsoft.public.platformsdk.security)
  • Re: Can I create a remote object without a DLL on the client?
    ... There is no magic -- the client needs to know SOMETHING about the ... server if it wants to interact with it. ... Look at it another way -- why not prototype some client code that would ... because that's the nature of these languages. ...
    (microsoft.public.dotnet.framework.remoting)
  • Re: Microsoft Asyncronous TCP Server Implementation Example Proble
    ... End Sub 'StartListening ... > And you posted client code, please show server code for us. ... >> I have a problem with a TCP Asyncronous Server Implementation. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Multithreaded COM server problem...
    ... >>Note that this flag is effeectively ignored for the server. ... The problem is that your client code is not running a message loop. ... you change the loop of your client test code to something like: ...
    (comp.lang.python)