[Stackless] pi-ton 2.9 / Gillesspie
tismer at stackless.com
Tue Dec 31 01:55:52 CET 2013
On 30.12.13 23:54, Kristján Valur Jónsson wrote:
> Alex Gaynor just blogged about the failed state of 3.x and the need to
> give in and produce a better 2.x
Yes this is true, and very interesting reading.
Anyway, I do not want to see anybody mentioning piton and "2.8" in the same
paragraph or subject line, before a revised PEP 0404 is available that
We are in fact building a Stackless 2.8, which has a few back-ports.
It will go online in January.
At the same time, I am really thinking of a slightly more drastical change
of Python, that is over-due, and not that hard to do as people might think:
I want to go for a GIL-Less Python.
That Python uses thread- (or better tasklet-) local storage instead of
To make that possible, a completely new storage class needs to be installed,
probably with a new keyword. This storage class will be automatically used
by tasklets. They will use copy-on-write semantics to make all modifications
The namespace is named "non-shared".
The idea is to let things by default happen only locally, in a
Objects that are not in the local namespace are installed copy-on-write,
creating a non-shared object after being touched.
The info about being sharable or non-shared is a new attribute for every
object. The implementation is undecided, but may be implicit by using
the memory pool information.
A tasklet that uses "non-shared" data can run without the GIL, until it
writes other data that it does not own privately.
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.
But the idea is to de-couple threads of python execution as much as
without making Python an intractable beast.
For "normal" applications, Stackless 2.9 should just work as expected.
But whenever the effect of an action should be globally visible, an extra
function call is needed that opens the hidden state to others.
This is the rendevous case that we try to avoid, most of the time.
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.
As always, I am better at assigning a code name than creating a really one.
My suggestion is:
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 want to regard this post as an undirected starter.
Christian Tismer :^) <mailto:tismer at stackless.com>
Software Consulting : Have a break! Take a ride on Python's
Karl-Liebknecht-Str. 121 : *Starship* http://starship.python.net/
14482 Potsdam : PGP key -> http://pgp.uni-mainz.de
phone +49 173 24 18 776 fax +49 (30) 700143-0023
PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04
whom do you want to sponsor today? http://www.stackless.com/
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Stackless