[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