[Python-Dev] Feature Request: Py_NewInterpreter to create separate GIL (branch)
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