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®
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4