global interpreter lock

[Bryan Olson]

Mike Meyer wrote:
 > The real problem is that the concurrency models available in currently
 > popular languages are still at the "goto" stage of language
 > development.  Better models exist, have existed for decades, and are
 > available in a variety of languages.

That's not "the real problem"; it's a different and arguable
problem. The GIL isn't even part of Python's threading model;
it's part of the implementation.

 > It's not that these languages are for "thread-phobes", either. They
 > don't lose power any more than Python looses power by not having a
 > goto. They languages haven't taken off for reasons unrelated to the
 > threading model(*).
 >
 > The rule I follow in choosing my tools is "Use the least complex tool
 > that will get the job done."

Even if a more complex tool could do the job better?

 > Given that the threading models in
 > popular languages are complex and hard to work with, I look elsewhere
 > for solutions. I've had good luck using async I/O in lieue of
 > theards. It's won't solve every problem, but where it does, it's much
 > simpler to work with.

I've found single-line-of-execution async I/O to be worse than
threads. I guess that puts me in the Tannenbaum camp and not the
Ousterhout camp. Guido and Tannenbaum worked together on Amoeba
(and other stuff), which featured threads with semaphores and
seemed to work well.

Now I've gotten off-topic. Threads are winning, and the industry
is going to multiple processors even for PC-class machines.
Might as well learn to use that power.


-- 
--Bryan