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

[Gordon McMillan]

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, so can't
install it's import hooks into the right one.

At least, that's my recollection of the problems
I was having before I gave up. My understanding
of COM is relatively superficial. I understand the
Python part better, but certainly not completely,
(there were things I thought *should* work that
I couldn't get working).
 
There may even be a reason to want multiple
interpreter states. My understanding of COM
and threading is not deep enough for me to
make a coherent statement of requirements.
But pretty clearly Python's thread API doesn't
let me get anywhere close to handling
multiple Pythons in one process.

-- Gordon
http://www.mcmillan-inc.com/