[Python-3000] the future of the GIL

[Josiah Carlson]

James Y Knight <foom at fuhm.net> 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