[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
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)
the user inherits from the tasklet object and gets direct access to the 
tasklet's values
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

More information about the Stackless mailing list