global interpreter lock

[Donn Cave]

In article <91nNe.620$zD3.198 at newssvr29.news.prodigy.net>,
 Bryan Olson <fakeaddress at nowhere.org> wrote:

> km wrote:
>  > Hi all,
>  >
>  > is true parallelism possible in python ? or atleast in the
>  > coming versions ? is global interpreter lock a bane in this
>  > context ?
> 
> No; maybe; and currently, not usually.
> 
> 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.
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.  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.

   Donn Cave, donn at u.washington.edu