Global Locking

[Michael Chermside]

 > [Dan expresses interest in changing Python to avoid needing
 >  a global interpreter lock.]

I don't understand (or, more accurately, I am not sure YOU understand) 
exactly what you hope to gain from this modification.

If, for example, you have a multi-processor machine and you are hoping 
to be able to write programs in Python that use multiple processors at 
once WITHOUT coding any of it in C, then you'll need to get rid of the GIL.

But that's a pretty extreme situation (and can be better handled in 
other ways). Let me tell you what *is* possible, despite the GIL:

(1) A Python program can continue to execute while some threads are 
blocked for I/O operations. This is because the I/O routines do not hold 
onto the GIL.

(2) A Python program can "switch" between threads between ANY two python 
VM bytecodes. However, each VM bytecode is executed atomically, so you 
never do half of a "pop-top", half a "binary_add", or half of a c-based 
function like list.sort.

(3) A Python program can (does!) take advantage of the native threading 
provided by the operating system.

If you are interested in rapid context switches, you might also want to 
check out http://www.stackless.com/ where you can learn about (and use!) 
Christian Tismer's "stackless python", a version implementing 
microthreads (EXTREMELY lightweight threads).

-- Michael Chermside