Talk:Stackless Python

No more continuations?

I wish to mention that this artical is several years out of date. Stackless no longer supports continuations, as mentioned in a message posted by Christian Tismer to the Stackless Mailing list on March, 2004. Newer versions have light weight threads called tasklets. --Lenard Lindstrom 17:42, 24 July 2005 (UTC)

partially true

Well this is true in the sense that the article includes old information. Continuations were the target of the first implementations, later on I changed to the less powerful but easier to understand taskletmodel, which is some kind of one-shot continuations. Actually, this appears to be the only kind of continuations commonly understood.

partially false

It is false in the sense that Stackless of course has continuations in their full sense, that is you can take a snapshot of a running program and start this several times, concurrently. It is not directly supported any longer, but running tasklets may be pickled. It is up to the user to load a stored tasklet from disk multiple times. This is almost like full continuations, despite the fact that the variables are not shared between the instances.

Christian Tismer, creator of Stackless Python -- 15:02, 18 August 2005

Isn't it crucial for invoked continuations to refer to the same environment as they did when they were captured? I think most of the things continuations are used for are impossible if that isn't the case.

And about the tasklets: are they really one-shot continuations, or coroutines? In other words, can you invoke previously-captured continuations of a tasklet, or just suspend/resume the current tasklet? --Piet Delport 10:10, 8 March 2006 (UTC)

Yes, you are right, and I stand corrected. The cloning of tasklets cannot be compared with continuations.

And about the tasklets: I thought of a one-shot continuation because the continuation inside the tasklet is not restartable, but a different one after suspend/resume. But I think that makes no sense, it is actually a coroutine. I should probably be more aware of the literature. Tismer (talk) 16:56, 26 September 2010 (UTC)

Expanding on this page

I think that talking to the author of the following article and reusing the bulk of it where it doesn't specifically apply to game programming would allow a more extensive entry here: http://harkal.sylphis3d.com/2005/08/10/multithreaded-game-scripting-with-stackless-python/

Richard Tew, user of Stackless Python

A glaring omission

Look, I fancy myself as a computer scientist even when I'm really a plain ordinary Sunday programmer who knows a lot of tiny little details but fails to understand the big picture at times. I know what a stack is, and what Python is, but this article fails to answer a rather big question why I wanted to read the article in first place: what good it is? Is it faster? More efficient? More secure? More suited for specific tasks where ordinary Python doesn't cut it? "It's Python, without the stack" isn't very informative. If this be clarified in the article, it'd be highly appreciated. --wwwwolf (barks/growls) 12:55, 30 May 2007 (UTC)

Agreed that this is needed--as far as I can tell the number 1 (only?) reason to use Stackless over regular Python is because it supports lightweight concurrency. Regular Python only supports concurrency through multiple processes, with all the performance and complexity implications that entails. But I am not an expert on either! rococo roboto 16:28, 19 June 2007 (UTC)

Essentially correct. "Stackless" just means that it uses a tree structure instead of stack(s) to keep track of the state of different threads. This allows cooperative-multitasking microthreads, and a few other interesting features. It's sort of a niche platform, because "micro" doesn't mean free. Each task eats up something like 20KB, and the scheduler isn't very fast, so it starts adding up to a major performance hit after a couple thousand tasks (original research). --Nasarius 20:54, 20 June 2007 (UTC)

This sounds somewhat funny. Where do the numbers come from? 20KB for what? Well, if you hit a special case and switch tasklets from inside a C extension, then you get more or less C stack crap to be saved, but the general case is much different: A few bytes, fust for the Python frames and a tiny tasklet structure, that's it. And why is the scheduler slow? It is at least 80 times faster than switching real threads. Tismer

In ordinary C-based Python, there is a commingling of the call stack for Python with the call stack for C. What I mean is that for one Python function or method to call another, it drops down into the C world and comes back up. State information connecting the caller and the callee lives on the C stack, unavailable to Python, so you can't do introspection with it.

A pure Python stack makes introspection possible, and additionally you can maintain a tree structure of stacks rather than a single stack. (The root of this tree is the C stack that starts off the first Python function/method.) The big win with the tree structure is, as Chris pointed out, is that you get fast light threads. You can see these and some other applications at http://code.google.com/p/stacklessexamples/. -- WillWare 17:49, 19 July 2007 (UTC)

This is correct except for the stack introspection, which CPython supports without difficulty. (See sys._getframe and sys._current_frames, and the inspect and traceback modules.) —Piet Delport 00:14, 20 July 2007 (UTC)

Sure, CPython does some introspection. But it is not able to modify the structure.

That is the big difference: Stackless can modify the execution state, easily, because it is not blocking structures on the stack, but has it available as a data structure.

But as it stands, now in 2018, CPython has achieved a lot of what Stackless had. It took 15 years, and they adopted a way more complicated way do squeeze all concurrency into generators, using "yield from" or the modern syntactic sugar, but it is far enough to say that Python 3.5 and up have solved the concurrency problem quite well.

What they have still not used is the feature of pickling program state. With Stackless, you can capture a running program, stop it and resume it later, or even on a different machine. That part of Stackless might still be a feature that could be adopted by CPython - of course with quite different details. — Preceding unsigned comment added by Tismer (talk • contribs) 16:23, 26 August 2018 (UTC)

Page needs more

Stackless isn't experimental now that's it's in 3 major commercial releases. The point about how much more easily conccurent processes are run as the major influence for choosing this product over regular Python needs expounding. A programmer would be better suited than I. Maybe look at Second Lifes developers' blogs for clues to this? Alatari (talk) 12:46, 5 August 2008 (UTC)

Examples

If no one objects, I'll try to write some examples that show Stackless's strengths versus vanilla Python. LoknarGor-The Jack of All Trades (talk) 01:45, 21 September 2009 (UTC)

That would be appreciated, please go ahead!--Tismer (talk) 17:42, 12 March 2010 (UTC)