Multithreaded COM server problem...

[Mark Hammond]

John Lull wrote:

> 1. Dig into exactly how apartment-threaded servers are supposed to be
> written in C or C++ & see how much of that is transferrable to Python.
> I'm not confident this would give me a solution, though.
...
> 3. Dig into why setting sys.coinit_flags=0 in localserver.py doesn't
> work. This is probably the right thing to do, both because I know it
> will yield a solution, and because it would solve the same issue for
> anyone else with similar needs. Unfortunately it means I have to dig
> into Python threading internals, pythoncom internals, and the whole
> COM mechanism rather more heavily than I'd hoped to.

I think these are pretty-much the same option.  The win32com extensions 
make no attempt to insulate you from these threading issues - it will 
blindly do what you ask.  In that regard, Python already acts very much 
like a C/C++ application - under the covers, we have a C++ pointer to a 
COM object, and when Python code tries to make a call, from whatever 
thread, we just make the call.  The same thing is true in reverse - we 
hand out a C++ pointer, and when an incoming call is made on that, we 
blindly call Python on that thread.

The Python GIL is in the picture, but I see no evidence it has any 
bearing in this case.  Certainly, in the simple example we started with, 
no threads were blocked waiting for this lock.

Re sys.soinit_flags - I am fairly confident that this will cause 
CoInitEx to be called with the specified flag as pythoncom is imported. 
  However, note that any exceptions raised by this function are masked 
when called implicitly during that import.  Try explicitly calling 
pythoncom.CoInitializeEx(0) near the top of localserver.py - any 
exceptions you see would also have happened for the implicit call made 
at import time.

I'd welcome any evidence that a C++ app would behave differently, and am 
keen to help you resolve (or at least explain) this for everyone's 
future benefit.

Mark.