"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