[Stackless] why the TaskletExit?

Andrew Dalke dalke at dalkescientific.com
Thu Jan 25 00:21:30 CET 2007

On Jan 24, 2007, at 5:43 PM, Richard Tew wrote:
> On 1/24/07, Andrew Dalke <dalke at dalkescientific.com> wrote:
>>      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:
>   main()

Interesting.  I've been digging through my memories and notes
from when I did stackless in August/September, trying to get
things together for my stackless presentation at PyCon.  So I'm
still shaky on things.

But part of it is because of the example at


import stackless

def Sending(channel):
     print "sending"

def Receiving(channel):
     print "receiving"
     print channel.receive()



I tried it just now without the schedule(task) and schedule(task2)
and it worked just fine.  Does the documentation need correction?

>> 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.

Now that I figured out the exception was from gc and not from
deadlock determination I understand why they can be different.

					dalke at dalkescientific.com

Stackless mailing list
Stackless at stackless.com

More information about the Stackless mailing list