Jython, GILs and object locking.
Jon Franz_antispam
jfranzXREMOVEX at neurokode.com
Thu Oct 16 13:56:35 EDT 2003
More information about the Python-list mailing list
Thu Oct 16 13:56:35 EDT 2003
- Previous message (by thread): Jython, GILs and object locking.
- Next message (by thread): Jython, GILs and object locking.
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
> I meant dynamic objects. In the Python code > a = b > the count for b gets incremented and the count of the object a points to > gets decremented. > > Reference counters are being changed almost everywhere in Python, when > tuples are created, when parameters are passed to a method etc. All this > will get slower because access to the counters has to be synchronized. > > One could try to remove reference counting along with the GIL, but that has > other repercussions, some for extension writers, some for the language > CPython (Jython has already these problems). What if the reference counter system became smart enough so that there were n+1 'pools' of objects? n thread-local pools, and one global pool (for objects that are in the global scope). This could be painful to implement, and would have far-reaching repercussions, but it would remove the locking on reference counting for local variables that only have meaning within a specific thread context. Of course, excessive use of global scope variables would lead to a lot of short term locks being grabbed and released by Py_INCREF and Py_DECREF, which could be more damaging than the GIL if not avoided. Making the system 'smart' enough to not lock and release when only one thread is running would be a good thing. I'm just thinking out loud here... thoughts? ~Jon Franz
- Previous message (by thread): Jython, GILs and object locking.
- Next message (by thread): Jython, GILs and object locking.
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Python-list mailing list