[Stackless] Semantic of schedule_remove
Alberto Ganesh Barbati
AlbertoBarbati at libero.it
Wed May 21 23:46:52 CEST 2008
Jeff Senn ha scritto:
> Hi Alberto-
> Check the doc string for stackless.schedule_remove
> import stackless
> print stackless.schedule_remove.__doc__
Thanks Jeff for the explanation. I believe that the doc, which I had
read, is defective. It says "switch to the next runnable tasklet and
remove self". However if the next runnable tasklet is self, the function
clearly cannot perform both tasks. In this corner case, I find it more
obvious to perform the remove rather than the (degenerate) schedule, but
apparently what is happening is the opposite. All in all, you might say,
the function is called schedule_remove()! Maybe it would be interesting
to have a function named remove_schedule() with the opposite semantic,
which is a much more useful behaviour IMHO. Or am I missing something
obvious that might make such a function impossible to implement?
In any case, I believe this case should be described explicitly in the doc.
> And then run this slightly modified example and see
> if the behavior is more obvious to you. (Note: that
> the "next runnable tasklet" could be yourself!
> I suppose this boundary condition might be considered
> a bit "astonishing".... :-)
> import stackless
> def run(name):
> print name, "start"
> myself = stackless.getcurrent()
> if stackless.schedule_remove() == myself:
> print "No one else to switch to! Continuing..."
The fact is that I do not want it to continue! I am using
schedule_remove() to implement a cheap sort of blocking call without
using a channel. In the complete example (the one I posted is just an
excerpt, for sake of explanation) the tasklet calls schedule_remove()
after requesting data which are going to be provided at a later time by
the main tasklet. Once the main tasklet has the data available, it
re-inserts the blocked tasklet in the runnable queue so that it can
continue. If the block doesn't happen, I am in big trouble because the
code would try to access data that is not yet available.
Sure I can use a channel, but that approach requires an extra object
(the channel itself) which is actually unnecessary.
More information about the Stackless