On 10/04/2012 06:14 PM, Andrew Francis wrote:
Hi Ronny:
------------------------------------------------------------------------
*From:* Ronny Pfannschmidt <ronny.pfannschm...@gmx.de>
*To:* Andrew Francis <andrewfr_...@yahoo.com>
*Cc:* Armin Rigo <ar...@tunes.org>; Sarah Mount <s.mo...@wlv.ac.uk>;
PyPy_Developers <pypy-dev@python.org>
*Sent:* Monday, October 1, 2012 2:51 PM
*Subject:* Re: [pypy-dev] PyPy STM
On 10/01/2012 08:32 PM, Andrew Francis wrote:
AF> That is why I use Stackless Python.... And I would love to try to
AF> incorporate STM into Stackless.
>no point in pushing that into old stackless
>once continulet-jit-3 works as we hope to, "continuations"
>will have distinct stacks (Armin please correct if i missed )
I view Stackless Python and its API as functioning at a higher level
than continuelets or some other low
level concurrency mechanism. As an example, look at the old stackless.py
module that supported both greenlets
and coroutines.
Maybe Stackless a few years from now, will be Stackless in API only
rather than under the hood
mechanisms?
as far as i understood, that will be the state once the continulet-jit-3
branch is done
it just gives each continuation a own stack, the rest is api
AF> I'll admit, I don't understand all the ins-and-outs of the papers.
AF> However my takeaway is that STM and STMish mechanisms are used in a very
AF> small place: the message passing system's implementation. Given that
AF> message passing systems typically share information through messages
AF> :-), this ought to create a very small footprint for transaction
conflicts.
stm will be everywhere in pypy because we need it everywhere
>to have it appear as if we still have the gil
Yes the STM mechanism will be everywhere. However I would suspect that
one would still want
to write programmes that would result in fewer transaction conflicts and
redo/undo work. It would be nice
to have programming constructs to do this (I guess atomic is one of
them).Message passing is another mechanism.
Message passing is a fairly easy model to understand.
i think that some fundamentals (aka channels/queues) will be enough
the rest is a question of the programming models/patterns
it will be interesting to figure good/new ones
Again, my point is that the literature points to using STM and STM like
features to build more efficient
message passing systems. It is this line of thinking that I feel is
worth pursuing. I don't know how the PyCSP
folks feel about this?
im under the impression that messages are to be used
to help with low conflict rates, but [[citation needed]]
i haven’t yet experimented with that enough
If you want to see an example of the headaches of using fine-grained
concurrency control to implement
channels, look at Go source code (i.e, you will see stuff like sorting
locks on channel data structures).
noted for in 2 months
-- Ronny
Cheers,
Andrew
_______________________________________________
pypy-dev mailing list
pypy-dev@python.org
http://mail.python.org/mailman/listinfo/pypy-dev
