James Y Knight <[EMAIL PROTECTED]> wrote: > On May 7, 2007, at 1:58 PM, Guido van Rossum wrote: > > As C doesn't have an atomic increment nor an atomic > > decrement-and-test, the INCREF and DECREF macros sprinkled throughout > > the code (many thousands of them) must be protected by some lock. > > 2) There's a pretty damn portable library which provides these > functions for what looks to me like pretty much all CPUs anyone would > use, under Linux, Windows, HP/UX, Solaris, and OSX, and has a > fallback to using pthreads mutexes: > > http://www.hpl.hp.com/research/linux/atomic_ops/index.php4 > http://packages.debian.org/stable/libdevel/libatomic-ops-dev > > > It's quite possible the overhead of GIL-less INCREF/DECREF is still > too high even with atomic increment/decrement primitives, but AFAICT > nobody has actually tried it. So saying GIL-less operation for sure > has too high of an overhead unless the refcounting GC is replaced > seems a bit premature.
Of course the trouble is that while this would be great for incref/decref operations, and the handling of certain immutable types, very many objects in Python are dynamic and require the GIL for all operations on them. Removing the need to hold the GIL for incref/decref operations and telling people "some objects don't need to hold the GIL when you monkey with them" is really just a great way to confuse the hell out of people. There is already confusion with borrowed references, which affects fewer types than would be affected if we were to say "some immutable c types can be accessed without the GIL". Could it offer speed up? Probably, but how much, and what kind of a PITA would it become to use and manipulate the immutable types? - Josiah _______________________________________________ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
