[Stackless] pi-ton 2.9 / Gillesspie

[Stefan Drees]

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,
Stefan.
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
>>
>> http://alexgaynor.net/2013/dec/30/about-python-3/
>>
>>
>>
>
> 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
> local.
>
> The namespace is named "non-shared".
>
> The idea is to let things by default happen only locally, in a
> sub-interpreter.
> 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
> possible,
> 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.
>
> Opinions?
>
> --
> 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
> http://www.stackless.com/mailman/listinfo/stackless
>