win32com: passing object to threads

Alex Martelli aleaxit at yahoo.com
Thu Feb 1 09:55:46 EST 2001


"Markus von Ehr" <vonehr at ira.uka.de> wrote in message
news:3A79690D.563A7248 at ira.uka.de...
    [snip]
> In another thread I want to set the New SoundFile:
>
>   Globals.mp.FileName = "null.wav"
>
> and I have the error:
>
>   Pythoncomerror, (-2147221008, 'CoInitialize hasn't been called', None,
> None)
>
> I know that I have to use the: pythoncom.CoInitialize() and
> pythoncom.CoUninitialize() in a way, but don't know why.
> Can anybody help me?

Each thread needs to call CoInitialize for itself -- that's
the COM rule.  Are you asking the "why" of this COM rule, or
the "why" it gets reflected down to your Python code for
all threads except the main one?

Assuming you accept both of these design decisions as
reasonable, the remaining meanings of "why" seem to follow:
as you are doing a COM operation from this other thread, the
thread needs to be COM-enabled.

A thread being "COM enabled" means it having told COM
explicitly exactly how it intends to operate within it -- in
what "apartment", in COM parlance.  This specific "explicit
is better than implicit" design decision by the Microsoft
COM team answers the first "why": COM refuses to guess
exactly HOW a given thread might want to operate with it.

As for the second "why", I don't think Python lets a package
(e.g. Pythoncom) "hook" some generic function on the event
"creation of an arbitrary new thread", so, even if implicitly
and magically COM-enabling all threads were a good architecture
(and I have my doubts), I don't see how Pythoncom might
implement that architecture.


Alex






More information about the Python-list mailing list