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

[Guido van Rossum]

(Interestign to see the PyObjC folks disagree. :-)

On 9/21/05, Ronald Oussoren <ronaldoussoren at mac.com> wrote:
>
> On 21-sep-2005, at 0:10, Bob Ippolito wrote:
> >
> > 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.
>
> For PyObjC having multiple interpreters in a process would cause me
> severe headaches. Due to the nature of PyObjC it would be way too
> easy to accidently access objects from one interpreter in another
> interpreter (in a hypothetical universe where it would be easy to use
> multiple interpreters). And lets not get started about the GIL, I
> don't think its accidental that PyGILState_Ensure only works with one
> interpreter.

Actually Python itself has a hard time keeping multiple interpreters
truly separate. Also of course there are some shared resources
maintained by the operating system: current directory, open file
descriptors, signal settings, child processes, that sort of thing.

If we were to completely drop this feature, we could make built-in
classes modifyable.

> A system like Java's classloader would be helpfull, where the
> classloader of a class is used to load the classes used by that
> class. I have no idea if this can be adapted to python at all. A
> strict coding style seems to work for now.

You can do something like this using the restricted execution support,
which works by setting the __builtins__ name in a dict where you exec
code, and overriding __import__ in that __builtins__ dict. (I can't
explain it too well in one paragraph, just go look up the rexec.py
source code.)

It's not great for guaranteeing there's absolutely no escape possible
from the sandbox, but it works well enough to make accidental resource
sharing a non-issue (apart from the OS shared resources and the
built-in types). A misfeature (for this purpose) is that certain kinds
of introspection are disabled (this was of course to enable restricted
execution).

I'd be willing to entertain improvements that improve the insulation
this provides.

--
--Guido van Rossum (home page: http://www.python.org/~guido/)