Hi Folks:
Some thoughts:
In playing with stackless.py, I liked the original version more than the
current version.
In the original stackless.py, one had the choice of low-level concurrency,
either greenlets if working with CPython, PyPy's coroutine library.
The latest version of stackless.py removed greenlet support. This is a pity. I
liked the layering, separating high level API from low level concurrency. I
grew up reading Andrew Tannenbaum and Douglas Comer.
I originally directly hacked on stackless.py. Now I realise this was a really
bad idea. One reason I haven't put join and select stuff in github is that I am
trying to refactor the code so I can get it running on C based Stackless
Python, CPython with greenlets, and PyPy. I have started. I have to revisit my
notes to give specifics but I found that it helps if the scheduler stuff has
more API functions. So one can even experiment with, say a channel
re-implementation with Stackless Python (as opposed to with stackless.py).
example:
selectStackless.py, code should look something like
# import underlying functionality
import stackless
# however we export selectStackless.py functionality
__all__ = 'run getcurrent getmain schedule tasklet channel select'.split()
# we re-implement channel
class channel(object):
.
.
# and select
def select(.....):
layer 3 - select, join, channel-reimplementations, whatever else
layer 2 - channels
layer 1 - Tasklets, scheduler, atomic
layer 0 - tealets, greenlets
As for PyPy continuations. I think the current problem is with pickling. When I
have time, I'll look for the reference in the PyPy mailing list.
Cheers,
Andrew
Message: 1
Date: Sun, 13 Apr 2014 12:07:37 -0400
From: Alain Poirier <[email protected]>
To: [email protected]
Subject: [Stackless] Sprinting at PyCon
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
Hi all,
I would like to discuss how it'd be possible or not for Stackless to follow the
same path than PyPy:
- A simpler Stackless core, with only the 'tealet' / '_continuation' stack
switch, writing in C. Exposing the same API than PyPy.
IIRC, Krisjan already has such a Stackless version.
- All the high level features of Stackless like Tasklets and Channels moved to
the 'stackless.py' pure Python module.
- An emulation of the greenlets API, in a 'greenlet.py' pure Python module.
- Bonus point if these 'stackless.py' and 'greenlet.py? modeules are shared /
co-developed with the PyPy project :)
I see several advantages then:
- Greenlets and Stackless features being Python modules, easier
experimentations
are possible. For example writing other scheduling policy or higher
concurrency
primitives such like Andrew's select/join.
- With a 'greenlet.py' compatible module, lots of softwares like ?gevent?
could
work without any modification.
- Works on 'greenlet.py' and 'stackless.py' can profit both to Python
Stackless
and PyPy.
Just my 2 cents,
Alain
------------------------------
Message: 2
Date: Mon, 14 Apr 2014 09:48:56 +0200
From: Anselm Kruis <[email protected]>
To: [email protected]
Subject: Re: [Stackless] Sprinting at PyCon
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Hi Alain,
another unique feature of Stackless is pickling/unpickling of tasklets
and many other python types. This feature is essential for many
applications and probably needs some additional C-code besides 'tealet'
/ '_continuation'. That said I like your proposal, but I doubt that we
have enough man power to implement it.
Cheers
Anselm
Am 13.04.2014 18:07, schrieb Alain Poirier:
> Hi all,
>
> I would like to discuss how it'd be possible or not for Stackless to follow
> the
> same path than PyPy:
>
> - A simpler Stackless core, with only the 'tealet' / '_continuation' stack
> switch, writing in C. Exposing the same API than PyPy.
> IIRC, Krisjan already has such a Stackless version.
>
> - All the high level features of Stackless like Tasklets and Channels
>moved to
> the 'stackless.py' pure Python module.
>
> - An emulation of the greenlets API, in a 'greenlet.py' pure Python module.
>
> - Bonus point if these 'stackless.py' and 'greenlet.py? modeules are
>shared /
> co-developed with the PyPy project :)
>
> I see several advantages then:
>
> - Greenlets and Stackless features being Python modules, easier
>experimentations
> are possible. For example writing other scheduling policy or higher
>concurrency
> primitives such like Andrew's select/join.
>
> - With a 'greenlet.py' compatible module, lots of softwares like ?gevent?
>could
> work without any modification.
>
> - Works on 'greenlet.py' and 'stackless.py' can profit both to Python
>Stackless
> and PyPy.
>
> Just my 2 cents,
> Alain
>
>
> _______________________________________________
> Stackless mailing list
> [email protected]
> http://www.stackless.com/mailman/listinfo/stackless
>
--
Dipl. Phys. Anselm Kruis science + computing ag
Senior Solution Architect Ingolst?dter Str. 22
email [email protected] 80807 M?nchen, Germany
phone +49 89 356386 874 fax 737 www.science-computing.de
--
Vorstandsvorsitzender/Chairman of the board of management:
Gerd-Lothar Leonhart
Vorstand/Board of Management:
Dr. Bernd Finkbeiner, Michael Heinrichs,
Dr. Arno Steitz, Dr. Ingrid Zech
Vorsitzender des Aufsichtsrats/
Chairman of the Supervisory Board:
Philippe Miltin
Sitz/Registered Office: Tuebingen
Registergericht/Registration Court: Stuttgart
Registernummer/Commercial Register No.: HRB 382196
------------------------------
_______________________________________________
Stackless mailing list
[email protected]
http://www.stackless.com/mailman/listinfo/stackless
End of Stackless Digest, Vol 123, Issue 9
*****************************************
_______________________________________________
Stackless mailing list
[email protected]
http://www.stackless.com/mailman/listinfo/stackless
