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
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
