[Stackless] pi-ton 2.9 / Gillesspie
andrewfr_ice at yahoo.com
Tue Dec 31 18:29:58 CET 2013
Hi Christian and Folks:
Date: Tue, 31 Dec 2013 01:55:52 +0100
From: Christian Tismer <tismer at stackless.com>
To: The Stackless Python Mailing List <stackless at stackless.com>
Subject: Re: [Stackless] pi-ton 2.9 / Gillesspie
Message-ID: <52C21618.6070805 at stackless.com>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
>I want to go for a GIL-Less Python.
>That Python uses thread- (or better tasklet-) local storage instead of
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.
>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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Stackless