[Stackless] pi-ton 2.9 / Gillesspie
stefan at drees.name
Tue Dec 31 19:17:54 CET 2013
top posting on the last day of the year :-)
I love the undirected starter below and thus give this night in tunesia
like idea some cpu core count dependend but true
+N (and not only for the code name Gillespy)
All the best,
On 2013-12-31 01:55 +01:00, Christian Tismer wrote:
> 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
> allows it.
> 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:
> First attempt:
> I want to go for a GIL-Less Python.
> That Python uses thread- (or better tasklet-) local storage instead of
> the globals.
> 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.
> Code Name
> As always, I am better at assigning a code name than creating a really one.
> My suggestion is:
> - 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 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/
> Stackless mailing list
> Stackless at stackless.com
More information about the Stackless