Mark Hammond wrote:
On 25/05/2010 11:27 AM, Don Dwiggins wrote:
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.
By "fail" here you mean "hang" right?
Yes.
The object model semantics are tricky - if the object says it only
supports single or apartment threading, COM is likely to marshal to
the main thread regardless of how the thread initializes COM.
The object is part of a DLL written in VB6. It's currently single
threaded -- apartment threading is the only other option in the IDE.
What is your main thread doing? Can you make it run a message loop to
test (ie, call pythoncom.PumpMessages() in that main thread?)
Hmm, I'll have to look at that. I'm running under a Twisted reactor,
and I'm not sure without looking how the reactor sets up the thread.
I'm not sure how (or why) PumpMessages would work here -- there's
nothing going on in the object that would require a Windows message loop.
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?
In the underlying call to COM's CoCreateInstance. I can't think of
*why* that could happen though...
OK, thanks. I may wind up moving this whole thing into a separate
"wrapper" process, to be invoked by the server. It's simple enough, and
there's no performance issue with doing that; it's just an annoyance.
Thanks,
Don
_______________________________________________
python-win32 mailing list
python-win32@python.org
http://mail.python.org/mailman/listinfo/python-win32
