[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.
Thomas
More information about the Python-Dev
mailing list