On 9/19/06, "Martin v. Löwis" <[EMAIL PROTECTED]> 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. _______________________________________________ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
