[Stackless] Re: [Python-Dev] Stackless Design Q.
Jeff Senn
senn@maya.com
Wed, 20 Feb 2002 11:00:37 -0500
Wed, 20 Feb 2002 11:00:37 -0500
- Previous message: [Stackless] Re: [Python-Dev] Stackless Design Q.
- Next message: [Stackless] Re: [Python-Dev] Stackless Design Q.
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Greg Ewing <greg@cosc.canterbury.ac.nz> writes: > It's not clear exactly what you're after here. Are you > trying to define the lowest-level interface upon which > everything else will be built? If so, I think what you > have presented is FAR too complex. > > It seems to me you need only two things: ... > t = tasklet(f) > t.transfer() (Sorry if I missed something -- I've been *way* busy lately and haven't been giving this much attention -- that said...) But (if I understand the current plan) we will need mechanisms internal to the Python interpreter to transfer values and maintain blocked/running state anyway; since when you generate a tasklet and run it: t = tasklet(f) t.transfer() 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 haven't thought enough about the "unamed produce-and-continue function" to decide how exactly it should work. I have two concerns in implementing uthreads this way (scheduler in C): 1 -- there doesn't seem to be anyway to "kill" a tasklet 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? -- -Jas -------------------- www.maya.com Jeff Senn | / / |-/ \ / /|� Chief Technologist | /|/| |/ o | /-| Head of R&D | Taming Complexity�
- Previous message: [Stackless] Re: [Python-Dev] Stackless Design Q.
- Next message: [Stackless] Re: [Python-Dev] Stackless Design Q.
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]