[Stackless] Re: [Python-Dev] Stackless Design Q.

[Greg Ewing]

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