[Stackless] why the TaskletExit?

[Andrew Dalke]

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

http://www.stackless.com/wiki/Channels


import stackless

def Sending(channel):
     print "sending"
     channel.send("foo")

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

ch=stackless.channel()

task=stackless.tasklet(Sending)(ch)
stackless.schedule(task)
task2=stackless.tasklet(Receiving)(ch)
stackless.schedule(task2)
stackless.run()


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.

					Andrew
					dalke at dalkescientific.com


_______________________________________________
Stackless mailing list
Stackless at stackless.com
http://www.stackless.com/mailman/listinfo/stackless