Hi Kristján, Le 14 avr. 2014 à 09:44, Kristján Valur Jónsson <krist...@ccpgames.com> a écrit :
> 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) > > 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? Sorry, I see my writing of this proposal is confusing because it describes the "how" before the "why" and also not with the correct priorities. As I answered to Anselm, my main goal would simply to have a greenlet-like API in Stackless to be able to share / run the greenlets eco-system (i.e gevent), but never to remove the soft-switching or the tasklets pickling (you know very well how badly we depend on this Stackless feature ourself). It was an attempt to respond to one of the sprint idea: to have gevent running on Stackless. It’s something I experimented during the Pycon 2013 sprints. But I found the gevent hub so tightly bound to the greenlets API that I ended using the « greenlets in stackless » emulation layer of Syncless https://code.google.com/p/syncless/source/browse/trunk/syncless/greenlet_using_stackless.py. However, even if that seems to work (not tested in production), emulating the greenlets on top of Stackless always feels horribly « upside down » to me. Having a native greenlets API seems more natural. And then I was wondering if Stackless couldn’t have the same structure than PyPy where the greenlets and Stackless features are built on a lower level simpler core API. Best regards, Alain > -----Original Message----- > From: stackless-boun...@stackless.com > [mailto:stackless-boun...@stackless.com] On Behalf Of Alain Poirier > Sent: 13. apríl 2014 16:08 > To: stackless@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@stackless.com > http://www.stackless.com/mailman/listinfo/stackless > > _______________________________________________ > Stackless mailing list > Stackless@stackless.com > http://www.stackless.com/mailman/listinfo/stackless _______________________________________________ Stackless mailing list Stackless@stackless.com http://www.stackless.com/mailman/listinfo/stackless
