Hi, the following is a collection of unfinished thoughts. after my thesis i'll be experimenting with a relaxed csp-ish model based on python native generator based continuations as well as the new continulet-jit-3 based greenlets. my basic assumption is that having limited amount of shared memory is acceptable. the csp-ish "processes" are to be modeled as generators with yield expressions or green-lets and will assume a strong data locality. all communication will be started by suspending the execution and "switching away" with some payload that kind of starting/stopping seems to lend itself well to stm transactions basically one iteration of a generator will be one transaction and internal communication will also be separate transactions my current hypothesis is that such a model will lend itself to easy parallel execution since iteration steps of different continuations will be mostly completely independent and can just run in parallel. communication itself will be in transactions with higher conflict potential, but i assume that armin will find ways to evade the conflict issues with in-process communication channels, so i'm not going to think about it more till it turns out to be an actual problem in experimentation My main focus with those experiments will be concurrent systems. -- Ronny On 09/30/2012 11:10 AM, Russel Winder wrote:
Armin,
Sarah and I are restarting our work on CSP, and extending to creating actors and a dataflow library. It would be good to make this work on Jython, IronPython and PyPy as well as CPython. However we want to get away from a reliance on multiprocessing since it is rather heavyweight for the sort of parallelism we are after. STM as an infrastructure layer in PyPy and CPython would get us away from the GIL and allow for using Python threads bound to kernel threads to allow a single Python process to allow us to create lighweight processes (no application level shared memory).
Is the STM variant of PyPy and/or CPython in any form of usable state? If so then we can investigate building from source for ourselves so as to use it as a foundation for building the higher abstraction parallelism for applications programmers.
Thanks.
_______________________________________________ pypy-dev mailing list pypy-dev@python.org http://mail.python.org/mailman/listinfo/pypy-dev