On 09/30/2012 04:22 PM, Armin Rigo wrote:
Hi Ronny,
On Sun, Sep 30, 2012 at 3:50 PM, Ronny Pfannschmidt
<ronny.pfannschm...@gmx.de> wrote:
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.
What you are thinking about is to start from the naturally multicore
model of separate address spaces, and add some amount of shared
memory. You would use STM to handle the result. It is the opposite
of what I'm thinking about, which is to start with a non-multithread,
non-tasklet-based program and add multicore capability to it. I would
be using STM to "create" multicore capability, whereas you would be
using it to "create" shared memory. I am more interested in the first
approach than the second because I think it is closer to what
untrained programmers start with, but both approaches are potentially
valid.
i think both approaches are valid,
they lend themselves to help and reason about different kinds of
problems that make different kinds of serial programs concurrent and
parallel.
i think for most purposes simple sequential communicating programs
are way more easy to reason about than anything else.
the transaction module approach already seems to require to chunk up
programs in semi-small transactions,
that may cause other transactions to be scheduled
which seems more and more like twisted's defereds.
to my eyes twisted style code is a kind of spaghetti
that is very hard to reason about.
which is why i want to experiment executing multiple longer sequential
programs in chunks that may be interleaved and/or parallel
the reason why i start with generators instead of green-lets is simply
cause they cannot ever be nested.
this will allow more simple reasoning.
Russel: STM is a powerful tool that makes sense of shared memory in
multicore situations. I fail to understand why you are looking at it
in the absence of shared memory...
Im under the impression the intent is to have non-shared application
state while the interpreter states are still shared
(i might be using the wrong words here)
A bientôt,
Armin.
-- Ronny
_______________________________________________
pypy-dev mailing list
pypy-dev@python.org
http://mail.python.org/mailman/listinfo/pypy-dev
