[Stackless] Sprinting at PyCon

Jeff Senn senn at maya.com
Mon Apr 14 21:51:35 CEST 2014


On Apr 14, 2014, at 9:44 AM, Kristján Valur Jónsson <kristjan at ccpgames.com> wrote:

> Hi there.
> 
> I'm not entirely sure about the benefit of such a re-architecture.
> As I see it the chief benefits of Stackless over greenlets, are:
> 1) Pickling of runtime state.
> 2) Scheduling and higher level primitives implemented in C
> 3) "stackless" excecution of certain builtin python things. (soft switching as opposed to stack slicing) .  Allows for example soft stack switch in an __enter__/__exit__ method (an experimental feature).   Soft switching primarily allows tasklet state to be pickled and restored, but it is supposedly also for performance of execution of regular python code (this last claim is unproven)

I figure you should consider it “anecdotal”, but for my use (lots of relatively “parallel” pure-python tasklets with messaging between them to implement an asynchronous event-based scripting environment), the performance benefits (cpu as well as heap footprint) of soft-switching over stack slicing are quite profound.

> If we didn't need either, we could implement stackless as a .py module that relies on greenlets.  Then "stackless" would be just another greenlet client.

> Pickling can certainly be implemented in a more slim implementation, but picling of an execution state relies on "soft" switching.  
> Reasoning about the performance is harder but we always want to be fast :)
> 
> So, what can we throw away and how can we restructure to make things simpler, while keeping the essential benefits of stackless?
> 
> 
> 
> -----Original Message-----
> From: stackless-bounces at stackless.com [mailto:stackless-bounces at stackless.com] On Behalf Of Alain Poirier
> Sent: 13. apríl 2014 16:08
> To: stackless at stackless.com
> Subject: [Stackless] Sprinting at PyCon
> 
> 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
> Stackless at stackless.com
> http://www.stackless.com/mailman/listinfo/stackless
> 
> _______________________________________________
> Stackless mailing list
> Stackless at stackless.com
> http://www.stackless.com/mailman/listinfo/stackless
> 




More information about the Stackless mailing list