[Python-3000] Kill GIL?

Calvin Spealman ironfroggy at gmail.com
Wed Sep 20 04:54:07 CEST 2006


On 9/19/06, "Martin v. Löwis" <martin at v.loewis.de> wrote:
> Nick Coghlan schrieb:
> > I was thinking it would be easier to split out the Global Interpreter Lock and
> > a per-interpreter Local Interpreter Lock, rather than trying to go to a full
> > free-threading model. Anyone sharing other objects between interpreters would
> > still need their own synchronisation mechanism, but something like
> > threading.Queue should suffice for that.
>
> The challenge with that is "global" (i.e. across-interpreter) objects.
> There are several of these: the obvious singletons (None, True, False),
> the non-obvious singletons ((), -2..100 or so), and the extension module
> globals (types, and in particular exceptions).
>
> Do you want them still to be global, or per-interpreter?
>
> Regards,
> Martin

It is one fixable problem among many, but fixable none-the-less. Any
solution is going to break the API, but that should be allowed,
especially for something as important as this. The obvious and
non-obvious singletons don't represent much of a real problem, when
you realize that you'll have to change the locking API anyway, at
least to specify some interpreter ID for which to operate on its Local
Interpreter Lock. Should you check every object on what it is? No, so
either don't have cross-interpreter globals, which it doesn't save you
much anyway, or add a lock pointer to all PyObject structs, which can
be a single GIL, a LIL, or something else down the road. The API will
need to add a parameter to the locking anyway, so the door is already
open and singletons arent getting in the way.


More information about the Python-3000 mailing list