[Stackless] why the TaskletExit?

Richard Tew richard.m.tew at gmail.com
Wed Jan 24 18:43:39 CET 2007

On 1/24/07, Andrew Dalke <dalke at dalkescientific.com> wrote:
> Note that if I change
>      stackless.tasklet(main)()
>      stackless.run()
> to
>      stackless.schedule(main)()

This does not do anything.  schedule takes one optional argument
called retval, which happens to be a value it returns.  So this is
equivalent to:


So what happens when main gets run is that you are still on
the main tasklet, there are no other running tasklets, therefore
stackless knows there is no point in blocking.

> then I get
> Traceback (most recent call last):
>    File "counter.py", line 25, in <module>
>      stackless.schedule(main)()
>    File "counter.py", line 21, in main
>      val = chan.receive()
> StopIteration: the main tasklet is receiving without a sender available.
> I did track that down to  Stackless/module/scheduling.c but couldn't
> figure out why StopIteration was better for that case than TaskletExit.

Because the current tasklet (which happens to in this case be the main
one) is not exiting and this is not an error which should cause it to.
StopIteration does seem to be an arbitrary choice, but TaskletExit is
definitely the wrong one for the job.

Hope this helps,

Stackless mailing list
Stackless at stackless.com

More information about the Stackless mailing list