[Stackless] [Python-Dev] Stackless Design Q.
p.vrijlandt at aig.azn.nl
p.vrijlandt at aig.azn.nl
Thu Feb 21 08:47:44 CET 2002
> > But auto-scheduled frames are a diffeent kind
> > of thing than those which are in "waiting for data"
> > state. I need to distinguish them or I will crash.
> If you get rid of the idea of passing values between tasklets as part
> of the switching process, then this distinction disappears. I think
> that value-passing and tasklet-switching are orthogonal activities and
> would be better decoupled.
Hi all,
It seems to me that the proposed interface has these properties:
1. there are tasklets-objects
2. to define what the tasklet does:
a tasklet has a constructor, which takes a function as a parameter
OR
the user inherits from the tasklet object (is this feasable?) and overides
the 'job' or 'run' or whatever method
3. a tasklet can transfer execution to a designated tasklet.
This has previously been called transfer, but I propose
t.resume() for this. This function of course puts the current tasklet on hold.
4. for passing data between tasklets the options are:
using a parameter and return value as in return_value = t.resume(argument)
OR
the user inherits from the tasklet object and gets direct access to the
tasklet's values
OR
a common space is used for exchanging values
5. to implement a scheduler we would need a way to deal with tasklets that do
not voluntarily transfer execution to the scheduler. Resuming another tasklet
might or might not be a good excuse not to do so; this is to the implementor
of the scheduler.
6. users will want to define their own schedulers, so they can implement
tasklet priorities &c.
Probably being able to inherit from tasklet would make things easier.
Does this cover it all?
--
Patrick Vrijlandt
_______________________________________________
Stackless mailing list
Stackless at www.tismer.com
http://www.tismer.com/mailman/listinfo/stackless
More information about the Stackless
mailing list