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

[Greg Ewing]

Jeff Senn <senn at maya.com>:

> That may cause many more tasklets to be generated, run, and
> destroyed that you don't ever see ...  recursions/function calls in
> f, and only-Christian-knows what else...  so the transfer value
> mechanism might as well be built in.

I don't understand what you mean. Are you saying that every function
call creates a new tasklet? That stack frame == tasklet?  If that's
the case, then we're back to continuations! But I don't think so,
because Christian said that a tasklet contains "a chain of frames",
not just one frame.

> 2 -- the scheduling algorithm will be hard to tune (we'll probably
>      *at least* need tasklet priority...)  Maybe there should still
>      be a "timeslice" function so an in-Python scheduler can be written?

The huge variety of possible scheduling policies is all the more
reason *not* to make scheduling part of the core functionality.
The user should be free to implement his own scheduling layer
on top of the primitives if he doesn't like what is provided.

Greg Ewing, Computer Science Dept, +--------------------------------------+
University of Canterbury,	   | A citizen of NewZealandCorp, a	  |
Christchurch, New Zealand	   | wholly-owned subsidiary of USA Inc.  |
greg at cosc.canterbury.ac.nz	   +--------------------------------------+
_______________________________________________
Stackless mailing list
Stackless at www.tismer.com
http://www.tismer.com/mailman/listinfo/stackless