[python-win32] Python service hangs in Dispatch when frozen with py2exe

[Don Dwiggins]

Mark,

Thanks for the feedback.
> It might be worth making a call to 
> pythoncom.CoInitializeEx(pythoncom.COINIT_MULTITHREADED) in the thread 
> which is doing this work.
Yes, I've tried both apartment and multithreading models (building the 
DLL each way and using the corresponfing COINIT flag) -- no luck there.  
I've even built the project (VB6) as an EXE, and using the clsctx 
argument of Dispatch to call it as such -- same result.
> I *suspect* the problem will be related to when the import of 
> pythoncom happens in the 2 environments - when it is first imported, 
> it will call CoInitialize for you on that thread under the assumption 
> it is the "main" thread.  On a py2exe environment, it may be that for 
> obscure reasons, that first import of pythoncom happens on a different 
> thread. Googling for 'coinit_flags' should turn up more background 
> about how CoInit is done and can be controlled in pythoncom.

There's a good hint there.  I've got all my imports listed at the top of 
the file.  I do know that, when using the source, the file is read twice 
-- once from the command line by the usual Python interpreter, and once 
by PythonService; it must be different, though, when the compiled .exe 
is run both to install and to start the service.  I can't quite use the 
hint to figure out why it should fail when I do an explicit CoInitialize 
at the start of a thread.

I am almost sure by now that threads are involved, somehow; 
unfortunately, I still can't tell what I need to change to make it work 
properly.  To summarize what I've tried:

1. Running the service from the source:
  a. Calling Dispatch "in line" in the main thread: works.
  b. Putting the same sequence of code in a subthread: fails (no matter 
what permutation I use).

2. Freezing the 1.a code: fails.  (I haven't tried freezing 1.b)

I think (not sure) that the point where it hangs is always in 
pythoncom.new (for all permutations), where it's getting the OLE object 
to be wrapped.  The question is, where in that function could it hang up 
waiting for something to happen?

Again, thanks for your assistance,

-- 

Don Dwiggins
Advanced Publishing Technology


>
> On 25/05/2010 8:36 AM, Don Dwiggins wrote:
>> OK, I have more information that may help.  Looking into the code
>> invoked by IA.clsAuthorizeBatch(), I've found that the hangup occurs in
>> the call to pythoncom.new in CoClassBaseClass in
>> win32com\client\__init__.py.
>>
>> Interestingly, if I run the code in the "main" Twisted thread, it
>> executes without a problem (this is running the source, with py2exe out
>> of the picture). If I run it in a subthread (using Twisted's
>> DeferToThread) it hangs in the following call:
>>
>>> oo = pythoncom.new(IA.clsAuthorizeBatch.CLSID)
>>
>> .. where IA is the gen_py file, as before. The COM DLL is implemented in
>> VB with a single threaded model (although I've tried making it apartment
>> threaded as well).
>>
>> I can't go any deeper at the python level, since pythoncom is a DLL.
>>
>> As before, any advice appreciated ...
>>
>> I wrote previously:
>>> I'm developing a Python service under Win XP with Python 2.5 (the
>>> service is built on Twisted's XMLRPC server). For delivery to
>>> production, I "compile" it with py2exe. It's been running fine, but
>>> I've hit a snag.
>>>
>>> I've written new code to access a COM object (in a DLL); the code I've
>>> written does works successfully as long as I'm running the source
>>> under PythonService.
>>>
>>> The compiled version, however, hangs up in the call to Dispatch to get
>>> the COM object. I've put in debugging log entries all through the
>>> relevant section of code, and it's clear that it simply never returns
>>> from the Dispatch call. I've tried EnsureDispatch as well, and more
>>> recently the following code:
>>>
>>>> iab = IA.clsAuthorizeBatch()
>>>> auth = DispatchEx(iab.CLSID)
>>>
>>> ... where I've imported the gen_py module under the name IA (I've
>>> copied the module file to the same folder as the service, so there's
>>> no issue with py2exe or the executable not being able to find it). In
>>> this case, the hangup occurs in the first statement. I've tried
>>> running the code with and without wrapping it in
>>> CoInitialize/Couninitialize.
>>>
>>> I've run out of things I can think of to try, or even to get a hint of
>>> what might be getting hung up. One last bit of data: looking at the
>>> process in Process Explorer, I see that it's very busy for several
>>> seconds (about 50% CPU), then goes quiet.
>>>
>>> Any good words appreciated,
>>
>> _______________________________________________
>> python-win32 mailing list
>> python-win32 at python.org
>> http://mail.python.org/mailman/listinfo/python-win32
>