Hi Christian and Folks:
Message: 2
Date: Tue, 31 Dec 2013 01:55:52 +0100
From: Christian Tismer <[email protected]>
To: The Stackless Python Mailing List <[email protected]>
Subject: Re: [Stackless] pi-ton 2.9 / Gillesspie
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
>First attempt:
>-----------
>I want to go for a GIL-Less Python.
>That Python uses thread- (or better tasklet-) local storage instead of
>the globals.
Would you be building this on top of CPython? Or PyPy? I don't believe the
stackless features of PyPy have integrated with PyPy's STM yet. I believe
getting PyPy's Stackless features and STM integrated will allow for rapid
prototyping of approaches. I would like to help on this front.
>When a tasklet touches data that it does not own, then the regular
>actions dig in - either locking, or actions of an STM implementation,
>see the PyPy blogs.
My question is how do channels fit into this picture?
>The needed functionality can be folded into Python at some cost for the
>general case. But I think it can become very effective on modern hardware
>and current software paradigms. Simultaneous access to certain things
>can be avoided in over 95 % of typical observations.
Well I think in a well written Stackless Python programme, channels/message
passing results in the avoidance of simultaneous access to data most of the
time. This ought to be exploited. For better or worse, Go provides plenty of
literature on the design philosophy and issues surrounding channels and
concurrency.
Again, I have a hazy view but I suspect that an effective approach would be
based on limiting STM/lock-free algorithms to the channel mechanism. A smaller
transaction footprint would more readily allow one to exploit hardware based
STM. Again, this is all conjuncture on my part. I am trying to figure out how
best to explore some ideas.
>- Gillespy
>This is not only a contribution to Dizzy Gillespie, but also a word-playing
>game for those who wonder what a GIL-less Py should be.
I think that is a cool code name. I think a lot of improvisation and virtuosity
will be needed to for this project :-)
Happy New Year
Andrew
_______________________________________________
Stackless mailing list
[email protected]
http://www.stackless.com/mailman/listinfo/stackless
