On 10/04/2012 06:14 PM, Andrew Francis wrote:
Hi Ronny:
------------------------------------------------------------------------ *From:* Ronny Pfannschmidt <Ronny.Pfannschmidt@gmx.de> *To:* Andrew Francis <andrewfr_ice@yahoo.com> *Cc:* Armin Rigo <arigo@tunes.org>; Sarah Mount <s.mount@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