[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

AltStyle によって変換されたページ (->オリジナル) /