[Python-Dev] Extension modules, Threading, and the GIL

[Thomas Heller]

"Gordon McMillan" <gmcm@hypernet.com> writes:

> 
> Working with a (same version) Python app is actually
> a secondary worry. I'm more bothered that, for
> example, Excel can't load 2 frozen servers which
> use the same Python.

A COM component is useless IMO if it restricts which other components
you can use, or which client you use, and that's why I didn't allow
inproc COM servers in py2exe up to now.

But, since this problem doesn't occur with nonfrozen servers, it seems
the import hooks are the problem.

> 
> > I hope using the frozen module mechanism instead of
> > import hooks will make this more tolerant. 
> 
> But where are those modules frozen? How do they
> get installed in the already running Python? What
> if mulitple sets of frozen modules (with dups) want
> to install themselves?

I hope one could extend the FrozenModule table in an already running
Python by adding more stuff to it. Isn't there already code in cvs
which allows this?

> It ties into Martin's earlier comments about
> threading models. It may be that the solution
> lies in using COM's apartment threading, 
> instead of free threading. That way, the COM
> server could have it's own interpreter state, and
> the calls would end up in the right interpreter.
> Maybe.
> 
> But I don't understand the COM part well enough, 
> and Mark's stuff supports free threading, not
> apartment threading.  

Last I checked, win32all registers the components as
ThreadingModel = both. As I understand this, both STA and MTA
is supported (STA = Single Threaded Apartment, MTA = MultiThreaded
Appartment). So marking them as STA should be safe if it
is needed. Maybe Mark can clear the confusion?

> 
> I really brought all this up to try to widen the
> scope from extension modules which can
> easily grab an interpreter state and hold
> onto it.
> 

Thomas