Howdy Andrew,
On 31.12.13 18:29, Andrew Francis wrote:
Hi Christian and Folks:
Message: 2
Date: Tue, 31 Dec 2013 01:55:52 +0100
From: Christian Tismer <[email protected]
<mailto:[email protected]>>
To: The Stackless Python Mailing List <[email protected]
<mailto:[email protected]>>
Subject: Re: [Stackless] pi-ton 2.9 / Gillesspie
Message-ID: <[email protected]
<mailto:[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.
I think PyPy is doing well, and I don't want to compete.
No, at the moment I'm thinking of CPython, improving on it's Stackless
branch.
>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.
Not sure, yet. I'm still tinkering around with ideas.
And although PyPy-STM is the best solution per se, I hope to take some
advantage
of Stackless' isolation model of channels and to move a bit forward with
that.
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 :-)
Yes, until I become dizzy. ;-)
Seriously, I'm trying to materialize some idea between less separation
than the subprocess module, more separation than threads,
maybe using a generalization of the tasklet. Rough idea is a
multitasklet or mtasklet.
Based upon multiple interpreters, which are existent but doomed since
a millennium, interpreters could be almost as much separated as a
sub-process,
but still live in the same process space.
They would have disjoint memory pools, disjoint globals and disjoint
what-not,
but they have a chance to share something at wilt, and they don't suffer
the process
barrier.
Multitasklets could be the controlling instance of such interpreters,
and each would have its own thread pool, own malloc etc.
By construction, these interpreters can run in parallel, and each has
its own
GIL to suffer from.
Communication between these interpreters is _only_ possible via channels,
and that gives the cheap isolation. Exactly when such channels interact,
some serialization/locking/synchronizing happens that guarantees
defined transfers between the otherwise isolated, free-running interpreters.
How exactly the rendevouz would happen, and if we will support shared
objects or duplication of structures only - I don't know yet.
But I hope to know more until Mont-real - right now it is Mont-imag.
The fine-print is most probably much more difficult, but this approach looks
like something that has to be explored.
And I think to support this on Python 3 in the first place, so that nobody
thinks I am still on Python 2. That is just a matter of customer
support. ;-)
This foggy idea just got clearer, therefore the late response.
Played some music from 1942 while writing this...
happy NY - Chris
--
Christian Tismer :^) <mailto:[email protected]>
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
[email protected]
http://www.stackless.com/mailman/listinfo/stackless
