global interpreter lock

[Bryan Olson]

Donn Cave wrote:
 >  Bryan Olson wrote:
 >>On a uniprocessor system, the GIL is no problem. On multi-
 >>processor/core systems, it's a big loser.
 >
 >
 > I rather suspect it's a bigger winner there.
 >
 > Someone who needs to execute Python instructions in parallel
 > is out of luck, of course, but that has to be a small crowd.

Today, sure. The chip guys have spoken and the future is mult-
core.

 > I would have to assume that in most applications that need
 > the kind of computational support that implies, are doing most
 > of the actual computation in C, in functions that run with the
 > lock released.

That seems an odd thing to assume.

 > Rrunnable threads is 1 interpreter, plus N
 > "allow threads" C functions, where N is whatever the OS will bear.
 >
 > Meanwhile, the interpreter's serial concurrency limits the
 > damage.  The unfortunate reality is that concurrency is a
 > bane, so to speak -- programming for concurrency takes skill
 > and discipline and a supportive environment, and Python's
 > interpreter provides a cheap and moderately effective support
 > that compensates for most programmers' unrealistic assessment
 > of their skill and discipline.  Not that you can't go wrong,
 > but the chances you'll get nailed for it are greatly reduced -
 > especially in an SMP environment.

I don't see much point in trying to convince programmers that
they don't really want concurrent threads. They really do. Some
don't know how to use them, but that's largely because they
haven't had them. I doubt a language for thread-phobes has much
of a future.


-- 
--Bryan