Christian Tismer <tismer@tismer.com>:
Now I see it: You mean I can make this schedule function behave like a normal function call, that accepts and drops a dummy value?
Yes, that's right. (Or more precisely, it would take no parameters and return None.)
when I have a scheduler counter built into the Python interpreter loop
I can see the attraction of having pre-emption built in this way -- it would indeed be extremely efficient. But I think you need to make a decision about whether your tasklet model is going to be fundamentally pre-emptive or fundamentally non-pre-emptive, because, as I said before, the notion of switching to a specific tasklet is incompatible with pre-emptive scheduling. If you want to go with a fundamentally pre-emptive model, I would suggest the following primitives: t = tasklet(f) Creates a new tasklet executing f. The new tasklet is initially blocked. t.block() Removes tasklet t from the set of runnable tasklets. t.unblock() Adds tasklet t to the set of runnable tasklets. current_tasklet() A built-in function which returns the currently running tasklet. Using this model, a coroutine switch would be implemented using something like def transfer(t): "Transfer from the currently running tasklet to t." t.unblock() current_tasklet().block() although some locking may be needed in there somewhere. Have to think about that some more. For sending values from one tasklet to another, I think I'd use an intermediate object to mediate the transfer, something like a channel in Occam: c = channel() # tasklet 1 does: c.send(value) # tasklet 2 does: value = c.receive() Tasklet 1 blocks at the send() until tasklet 2 reaches the receive(), or vice versa if tasklet 2 reaches the receive() first. When they're both ready, the value is transferred and both tasklets are unblocked. The advantage of this is that it's more symmetrical. Instead of one tasklet having to know about the other, they don't know about each other but they both know about the intermediate object.
I want to provide an exception to kill tasklets. Also it will be prossible to just pick it off and drop it, but I'm a little concerned about the C stack inside.
As I said before, if there are no references left to a tasklet, there's no way it can ever be switched to again, so its C stack is no longer relevant. Unless you can have return addresses from one C stack pointing into another, or something... can you? Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | greg@cosc.canterbury.ac.nz +--------------------------------------+