2.6, 3.0, and truly independent intepreters

[sturlamolden]

On Nov 4, 6:51 pm, Paul Boddie <p... at boddie.org.uk> wrote:

> The language features look a lot like what others have already been
> offering for a while: keywords for parallelised constructs (clik_for)
> which are employed by solutions for various languages (C# and various C
> ++ libraries spring immediately to mind); spawning and synchronisation
> are typically supported in existing Python solutions, although
> obviously not using language keywords.

Yes, but there is not a 'concurrency platform' that takes care of
things like load balancing and testing for race conditions. If you
spawn with cilk++, the result is not that a new process or thread is
spawned. The task is put in a queue (scheduled using work stealing),
and executed by a pool of threads/processes.   Multiprocessing makes
it easy to write concurrent algorithms (as opposed to subprocess or
popen), but automatic load balancing is something it does not do. It
also does not identify and warn the programmer about race conditions.
It does not have a barrier synchronization paradigm, but it can be
constructed.

java.util.concurrent.forkjoin is actually based on cilk.

Something like cilk can easily be built on top of the multiprocessing
module. Extra keywords can and should be avoided. But it is easier in
Python than C. Keywords are used in cilk++ because they can be defined
out by the preprocessor, thus restoring the original seqential code.
In Python we can e.g. use a decorator instead.