when "normal" parallel computations in CPython will be implemented at last?

[Dan Stromberg]

If something happens with this for CPython, it'll likely come from Pypy
developers first.  They seem to be interested in doing things in a way that
is (or can be made) compatible with CPython.  If you want to help them
along, they're taking donations to fund the work, or you could donate your
own time.

Bear in mind that CPython threads fine for I/O-heavy workloads.  It's
CPU-bound workloads that CPython doesn't thread super well.

Last I heard, both Jython and IronPython thread well today, and there's
little reason not to try them if you have a (rather rare) application that
truly needs Java-like threading.  Granted, they don't run C extension
modules, but there's quite a bit of portability synergy to be had from
coming up with Pure Python alternatives; it's quite feasible to run the
same code on CPython 2.x, CPython 3.x, Pypy and Jython.  IronPython, sadly,
lacks a python standard library.

If CPython has trouble with CoW, it's probably because of reference
counting, not the GIL.  Last I heard, CPython used both reference counting
and garbage collection.  Also, vfork is a bit of a hack...  just plain fork
is often a better way to go.

On Sun, Jul 1, 2012 at 10:51 AM, dmitrey <dmitrey15 at gmail.com> wrote:

> hi all,
> are there any information about upcoming availability of parallel
> computations in CPython without modules like  multiprocessing? I mean
> something like parallel "for" loops, or, at least, something without
> forking with copying huge amounts of RAM each time and possibility to
> involve unpiclable data (vfork would be ok, but AFAIK it doesn't work
> with CPython due to GIL).
>
> AFAIK in PyPy some progress have been done (
> http://morepypy.blogspot.com/2012/06/stm-with-threads.html )
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-list/attachments/20120701/781a27c9/attachment.html>