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

[Thomas Heller]

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

> On 9 Jan 2003 at 14:23, Tim Peters wrote:
> 
> > Someone who cares about multiple interpreter states
> > should feel free to define and propose a stronger
> > requirement. However, the people pushing for change
> > here have explicitly disavowed interest in multiple
> > interpreter states, and I'm happy to press on
> > leaving them for afterthoughts. 
> 
> I have used multiple interpreter states, but not
> because I wanted to.
> 
> Consider in-process COM servers implemented
> in Python. When an application asks for the COM
> server, the COM support code will do the *loading*
> on a thread spawned by the COM support code.
> When the application *uses* the COM server, it may
> do so on it's own thread (it will certainly do so on
> a different thread than was used to load the server).
> 
> Installer freezes in-process COM servers. It does
> so by using a generic shim dll which gets renamed
> for each component. Basically, this dll will forward
> most of the calls on to Mark's PythoncomXX.dll.
> But it wants to install import hooks.
> 
> If it is the only Python in the process, everything
> is fine. But if the application is Python, or the user
> wants to load more than one Python based COM
> server, then there already is an interpreter state.
> Unfortunately, the shim dll can't get to it, ...

I cannot really believe this. Isn't it the same as for normal,
unfrozen inprocess COM servers?  The shim dll could do the same as
pythoncom22.dll does, or even rely on it to do the right thing.

Unfrozen inproc COM works whether the main process is Python or not.

> ... so can't
> install it's import hooks into the right one.

IMO, it's the frozen DLL rendering the Python
environment unusable for everything else (the main process,
for example). I hope using the frozen module mechanism
instead of import hooks will make this more tolerant.

All this may of course be off-topic for this thread.

Thomas