[Stackless] Stackless based replacement

Arnar Birgisson arnarbi at gmail.com
Fri Oct 3 09:34:27 CEST 2008

Hi Larry,

On Fri, Oct 3, 2008 at 01:01, Larry Dickson <ldickson at cuttedge.com> wrote:
> Wow! If that's your idea of a simple solution, I'd hate to see a complicated
> one ;-)

Well, if you look closely you'll see that it is basically a repeat of
the same pattern over and over:

def io_operation(*args,**kwargs):
    def callback():
        result = perform_real_io_operation(*args,**kwargs)
    return channel_dedicated_to_this_op.receive()

This pattern is simply applied to file.read, file.write, socket.send,
socket.recv and socket.accept. The sleep function is even simpler.

As for the dispatching tasklet:

def _loop():
   while _loop.running:
       if stackless.getruncount() == 1:
_loop.running = False

the time.sleep(0.0001) is simply an optimization in the case where
there are no other tasklets runnable, in which case this would become
a busy loop eating 100% of cpu. You could leave it out and the
semantics would hold, in which case the loop is simply:

while running:
    event.loop(True)      # dispatch any ready IO events
    stackless.schedule()  # run other tasklets

> Give me a week or so and I'll figure out how that works. What I do notice is
> the time.sleep(0.0001) [by the way, I believe the minimum sleep is actually
> 1 ms in older PCs and 2.5 ms in newer PCs].

2.5 ms? That's ages.. do you have some references for this?

> Unless C/Linux select is
> designed horribly (and it could be), my second select approach gets an
> instant response as soon as the hard interrupt handler returns control to
> the program. So my notion is not really reinventing the wheel - it is an
> improvement. And it seems to me it is an awful lot simpler. The only danger
> - like any select - would be huge numbers of simultaneously waiting IOs.

Well, libevent uses the best available method on each platform, for
linux I believe it uses epoll and not select.


More information about the Stackless mailing list