[Python-3000] Kill GIL?

[Ross Jekel]

I know it is a bit old, but would Python Object Sharing (POSH) 
http://poshmodule.sourceforge.net help you? Also, if you think you like the 
current state-of-the-art threading model, you might not after reading this: 

http://tinyurl.com/qvcbr 

This goes to an article on http://www.computer.org with a long URL entitled 
"The Problem with Threads." 

After some initial surprise when I learned about it, I'm now okay with a GIL 
or even single threaded python (with async I/O if necessary). In my opinion 
threaded programs with one big shared data space (like CPython's) are 
fundamentally untestable and unverifiable, and the GIL was the best solution 
to reduce risk in that area. I am happy the GIL exists because it forces me 
to come up designs for programs and systems that are easier to write, more 
predictable both in terms of correctness and performance, and easier to 
maintain and scale. I think there would be significant backlash in the 
Python development community the first time an intermittent race condition 
or a deadlock occurs in the CPython interpretor after years of relying on it 
as a predictable, reliable platform. 

I'm also happy the GIL exists because it forces alternative ideas like 
Twisted and stackless to be developed and tried. 

If you have shared data that really benefits from synchronized access and 
updates, write an extension, release the GIL at the appropriate places, and 
do whatever you want in a C data structure. I've done this when necessary 
and think it is the best of both worlds. I guess I'm assuming this will 
still be possible in Python 3000 (I haven't been on the list that long, 
sorry). 

There has to be a better concurrency model than threads. Let's design for 
the future with useful packages that implement the best ideas of today for 
scaling well without threads. 

Ross