global interpreter lock
gregpinero at gmail.com
Fri Aug 19 21:52:37 CEST 2005
Would a cheap solution just be to run two python interpreters and have the
scripts communicating over COM or some other such thing? I'd imagine that
would give you true parallelism.
On 8/19/05, Donn Cave <donn at u.washington.edu> wrote:
> 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
Chief Innovation Officer
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Python-list