[Python-Dev] GIL, Python 3, and MP vs. UP

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 mod_python 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.


More information about the Python-Dev mailing list