2.6, 3.0, and truly independent intepreters

[Christian Heimes]

Andy wrote:
> 2) Barriers to "free threading".  As Jesse describes, this is simply
> just the GIL being in place, but of course it's there for a reason.
> It's there because (1) doesn't hold and there was never any specs/
> guidance put forward about what should and shouldn't be done in multi-
> threaded apps (see my QuickTime API example).  Perhaps if we could go
> back in time, we would not put the GIL in place, strict guidelines
> regarding multithreaded use would have been established, and PEP 3121
> would have been mandatory for C modules.  Then again--screw that, if I
> could go back in time, I'd just go for the lottery tickets!! :^)

I'm very - not absolute, but very - sure that Guido and the initial 
designers of Python would have added the GIL anyway. The GIL makes 
Python faster on single core machines and more stable on multi core 
machines. Other language designers think the same way. Ruby recently got 
a GIL. The article 
http://www.infoq.com/news/2007/05/ruby-threading-futures explains the 
rationales for a GIL in Ruby. The article also holds a quote from Guido 
about threading in general.

Several people inside and outside the Python community think that 
threads are dangerous and don't scale. The paper 
http://www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-1.pdf sums it 
up nicely, It explains why modern processors are going to cause more and 
more trouble with the Java approach to threads, too.

Python *must* gain means of concurrent execution of CPU bound code 
eventually to survive on the market. But it must get the right means or 
we are going to suffer the consequences.

Christian