|WikiProject Computing / Software||(Rated Stub-class)|
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)
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.
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)
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)