[Stackless] why the TaskletExit?

Jeff Senn senn at maya.com
Wed Jan 24 18:37:44 CET 2007


Perhaps run.__doc__ which says:

   run_watchdog(timeout) -- run tasklets until they are all done, or  
timeout instructions have passed. ...

Should say this instead:

   run_watchdog(timeout) -- run tasklets until they are all done OR  
BLOCKED, ...
                                                                  
^^^^^^^^^^

What .run() really does is schedule while things CAN be scheduled.   
If you get into a
(detectable) deadlock (as in this case where there is simply nothing  
to run) then .run() will return.
It has to work this way because there is no place to take up the CPU  
time spinning and waiting
for nothing.

In the simplest case you could just do this:

   while 1:
     stackless.run()

But obviously that doesn't help much in general (except to spin your  
CPU).
You need to figure out why nothing is runnable and then take action.
There have been some other discussions about this on the list involving
inserting messages from other threads and such...

Your "TaskletExit" exception is happening because the whole thing is  
exiting -
i.e. it is the effect not the cause.

I'm not sure what you mean by (other than to guess that "exist"  
should be "exit"....):

>   From experimentation it looks like if there's no way for
> a tasklet to send anything then all tasklets blocked on a
> receive are told to exist.  That's guesswork and I would like
> clarification on the behavior.

Are you asking for some sort of send-a-message-that-destroys-the-channel
(and anyone waiting on it) feature?

-Jas


On Jan 24, 2007, at 11:50 AM, Andrew Dalke wrote:

> In the main tasklet I create another tasklet, which in turn
> creates a 3rd.  The 3rd send some data back to the 2nd then
> finishes.
>
> The 2nd tasklet always does a "receive" on the channel.  Once
> the 3rd tasklet finishes I expected either thread 2 to block
> or to get an exception derived from Exception.
>
> Instead I get a TaskletExit exception derived from SystemExit,
> causing a silent exit of the 2nd tasklet.
>
>   From experimentation it looks like if there's no way for
> a tasklet to send anything then all tasklets blocked on a
> receive are told to exist.  That's guesswork and I would like
> clarification on the behavior.
>
>    Looking through stackless.com and through the source didn't
> help me much.
>
> Question: why is TaskletExit called for this case?
>
>    Here's my test code
>
>
> import stackless
>
> def counter(chan, start, end):
>      print "Starting counter"
>      while start < end:
>          print "Sending value", start
>          chan.send(start)
>          start = start + 1
>      print "Counter finished"
>
> def main():
>      chan = stackless.channel()
>      # Start a new tasket and put it on the end of the task queue
>      stackless.tasklet(counter)(chan, 0, 4)
>      print "Created new tasklet"
>
>      while 1:
>          # Read from the channel.  If the channel is empty this
>          # yields control to another tasklet
>          val = chan.receive()
>          print "Received", val
>
> if __name__ == "__main__":
>      stackless.tasklet(main)()
>      stackless.run()
>
> Note that if I create a dummy tasklet which only schedules
> a few hundred thousand times then I delay the exit (meaning
> that the Stackless core knows there's the possibility of the
> channel being used).
>
> Note that if I change
>
>      stackless.tasklet(main)()
>      stackless.run()
> to
>      stackless.schedule(main)()
>
> 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.
>
> Question 2:  Why is the main tasklet treated differently?
>
> 					Andrew
> 					dalke at dalkescientific.com


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



More information about the Stackless mailing list