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 -- http://mail.python.org/mailman/listinfo/python-list
