[Python-Dev] GIL, Python 3, and MP vs. UP (original) (raw)

Thomas Heller theller at python.net
Wed Sep 21 20:59:11 CEST 2005

Bob Ippolito <bob at redivi.com> writes:

Personally my biggest issue with the way the CPython VM works is that you can't reliably do multiple interpreters in a single process. If that worked well, you could start an independent interpreter per thread and with a per-interpreter GIL you'd have pretty much everything you needed... but this would horribly break the C API and may be a performance hit.

My use case for this isn't so much about threads, but plug-ins. Writing multiple Python-based plug-ins for an application is always a mess, because they share too much (sys.modules, sys.path, etc.). PyObjC would benefit greatly from this feature, because you can write Python-based plug-ins for any Cocoa app that supports plug-ins, even if they're otherwise unaware of Python's existence. There are workarounds, of course, with import hooks and similar hacks. I think that modpython would also benefit from this, and probably other such systems.

Just a note in case you didn't know this already, probably off-topic for python-dev, but not meant as advertisement for py2exe): the same (plug-in) problem occurs with an inprocess COM server and a Python client program, or more than one inproc COM server in any client program. The 0.6 py2exe release with it's bundle-file option allows to build COM dlls (and client EXE programs, if needed) that APPEAR to have a statically linked copy of Python##.dll, and so have several CPython VMs running in the same process. In case anybody want's to take a look or experiment with it.

Thomas

More information about the Python-Dev mailing list