[Python-Dev] Feature Request: Py_NewInterpreter to create separate GIL (branch) (original) (raw)

Robert kxroberto at googlemail.com
Mon Nov 6 17:56:02 CET 2006

Talin wrote:

/ 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. / Nitpick: You have to remove all sharing of mutable objects. One day, when we get "pure" GC with no refcounting, that will be a meaningful distinction. :)

Is it mad?:

It could be a distinction now: immutables/singletons refcount could be held ~fix around MAXINT easily (by a loose periodic GC scheme, or by Py_INC/DEFREF to be like { if ob.refcount!=MAXINT ... )

dicty things like Exception.x=5 could either be disabled or Exception.refcount=MAXINT/.dict=lockingdict ... or exceptions could be doubled as they don't have to cross the bridge (weren't they in an ordinary python module once ?).

obmalloc.c/LOCK() could be something fast like:

_retry: __asm LOCK INC malloc_lock if (malloc_lock!=1) { LOCK DEC malloc_lock; /yield();/ goto _retry; }

To know the final speed costs ( http://groups.google.de/group/comp.lang.python/msg/01cef42159fd1712 ) would require an experiment. Cheap signal processors (<1%) don't need to be supported for free threading interpreters.

Builtin/Extension modules global dict to become a lockingdict.

Yet a speedy LOCK INC lock method may possibly lead to general free threading threads (for most CPUs) at all. Almost all Python objects have static/uncritical attributes/require only few locks. A full blown LOCK INC lock method on dict & list accesses, (avoidable for fastlocals?) & defaulty Py_INC/DECREF (as far as there is still refcounting in Py3K). Py_FASTINCREF could be fast for known immutables (mainly Py_None) with MAXINT method, and for fresh creations etc.

PyThreadState_GET(): A ts(PyThread_get_thread_ident())/TlsGetValue() would become necessary. Is there a fast thread_ID register in todays CPU's?

Robert

More information about the Python-Dev mailing list