[Stackless] Should I use stackless
andrewfr_ice at yahoo.com
Tue Jan 19 18:37:55 CET 2010
Date: Tue, 19 Jan 2010 11:19:06 +0200
From: Yuval <eyuval at gmail.com>
To: stackless at stackless.com
Subject: [Stackless] Should I use stackless
Message-ID: <94A21ACF-D1C5-40BF-A988-116D1B941E4B at gmail.com>
Content-Type: text/plain; charset=us-ascii
>1. The ability to freeze the script on a blocked channel and return to it >once data is made available.
I will assume you mean suspend a tasklet as opposed to freeze the script.
> So now for my questions:
>1. Am I missing something? Is there any fundamental reason the concept >shouldn't work?
Since you are dealing with networks, I think a big issue will be dealing
with blocking I/O, especially network based I/O. Since stackless tasklets execute in user space (within the context of an OS thread), the OS does not know about them. A consequence is if a tasklet makes a system call that blocks, all the tasklets in the thread are blocked. However there are solutions. You have a few choices ranging from asyncore, stacklesssocket to Twisted.
> b. Memory usage: Having these multiple frozen scripts assumes that >their memory utilisation is not extreme. Is there a large memory overhead >for each tasklet? How large is a typical frozen tasklet?
>From what I can tell, overhead for tasklets is very small. One of these
days I want to use guppy/Heapy (if it will work properly with stackless)
to get a better indication.
> c. Should I pickle the tasklet instead of freezing it and then rerun >it. Would that be extremely CPU intensive? Would pickling a tasklet be a >great memory saver? I should note that I expect most scripts to be pretty >basic. They should extend the device functionality but not replace its >core functionality.
I don't know what you mean by 'freeze'? The main thing that attracted me
to Stackless was the ability to pickle tasklets. In the world of electronic orchestration, this is called 'hydration.' In the world of business processes, it is possible for a programme to wait days if not weeks for a message to arrive (i.e., back ordering supplies)! If you have a lot of these critters, you may want to hydrate them. Another nifty possibility is if the load is too great on a machine, migrating them to another.
>3. The future: What's Stackless development model in relation to the main >Python branch.
So far it is tracking Standard Python.
>4. Any ideas on how to sell Stackless Python? I've been told that >scripting languages are like a religion, logic does not always enter into >the discussion ;-) , but I'm still trying.
Show something that is easy in Stackless but is really difficult in another language. Although I didn't have a chance to demonstrate it for the Montreal Python User's group, I have a version of the sieve of Eratosthenes that can be pickled and restarted.
More information about the Stackless