A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2006-November/069856.html below:

Py_NewInterpreter to create separate GIL (branch)

[Python-Dev] Feature Request: Py_NewInterpreter to create separate GIL (branch)Guido van Rossum guido at python.org
Mon Nov 6 05:52:46 CET 2006
On 11/5/06, James Y Knight <foom at fuhm.net> wrote:
>
> On Nov 4, 2006, at 3:49 AM, Martin v. Löwis wrote:
>
> > Notice that at least the following objects are shared between
> > interpreters, as they are singletons:
> > - None, True, False, (), "", u""
> > - strings of length 1, Unicode strings of length 1 with ord < 256
> > - integers between -5 and 256
> > How do you deal with the reference counters of these objects?
> >
> > Also, type objects (in particular exception types) are shared between
> > interpreters. These are mutable objects, so you have actually
> > dictionaries shared between interpreters. How would you deal with
> > these?
>
> All these should be dealt with by making them per-interpreter
> singletons, not per address space. That should be simple enough,
> unfortunately the margins of this email are too small to describe
> how. ;) Also it'd be backwards incompatible with current extension
> modules.

I don't know how you define simple. In order to be able to have
separate GILs  you have to remove *all* sharing of objects between
interpreters. And all other data structures, too. It would probably
kill performance too, because currently obmalloc relies on the GIL.

So I don't see much point in continuing this thread.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
More information about the Python-Dev mailing list

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4