Hello Glyph:

These examples aren't the greatest, because they tend to assume that you _always_ have Stackless code that's ready to run, and you want to run at some number of "frames per second". 

In 2007, folks (especially myself) are still trying to figure out if Stackless can play with Twisted correctly. I know my stuff in the repository is old.

For simple examples this makes sense, but for a system architecture this is a limiting approach.  If your stackless application wants to sit idle and wait for input, you're still going to wake up once every >1/30 second and checking to see if there's anything to do, burning CPU >cycles and battery life. 

An approach would be for the reactor tasklet to look at the runnable list to see if there are any entries. If there are no entries (i.e., tasklets are blocked and dependent on the reactor tasklet), then the reactor tasklet can stop the loopingCall. This is easy enough to do. However I suspect one starts to get into custom reactor land.

Also, if you want to run *faster* than the arbitrary timeout you've selected (1/30 second can be a very long time, especially if you're doing something pseudo-realtime, like audio playback) you're out of luck.

I believe there are two scenarios here: 1) no blocked tasklets and only runnable ones. If the runnable tasklets make no IO requests, it should be possible to put the reactor tasklet to sleep. Let the system run as fast as it can. 2) There is a mix of runnable (scheduled) and blocked tasklets. This scenario requires a more sophisticated scheduler that is trying to compute an optimal loopingCall value. This scenario is tricky.

Better would be to have tasklets schedule *themselves* for when they want to run. 

In the Stackless world, tasklets start running from the moment they are created/inserted into the runnable list. Stackless in non-preemptive mode is more about knowing when to make a tasklet yield to the scheduler. Cheers, Andrew