[Twisted-Python] Using a custom reactor in twisted trial for test cases?

[Andrew Francis]

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