[Stackless] Re: return values from tasklets

[Christian Tismer]

Dear Arman,

please post yopur proposal to the mailiong list!
I need discussion.

Also, please don't be upset if my former response was
quite short. I'm really on turkey, after five weeks
off smoking. I really have a hard time, and there is
yet no sign that it is over.
(No wonder after 30 years of nicotine abuse) :-)

> OK, here's my suggestion.  I can provide more details if you feel its
> too vague:

Some comments go here.

> * It seems wrong to me that tasklets call "schedule".  Scheduling
>   should be up to the scheduler.  My suggestion is that tasklets call
>   "yield_control" which yields control back to whoever called
>   tasklet.run.

Calling of schedule() is at the moment a thing that any code may
do at any time. There isn't any stack-like structure imposed
right now. That means that it is possible to jump between
arbitrary tasklets at any time.

The notation of tasklet.run() is arbitrary.
Currently, it only says that the spelled tasklet is put
into a position which lets it be run immediately, and
after it is done, *my* current tasklet is the next one in the
chain. But there is no guarantee that this will happen in this
order. That's the reason why I was asking.
Aaron Watters also asked me to make run() more restricted, like
guaranteeing that it will get back to "me".
This is possible, but it would enforce some structure like a "caller"
of tasklets. I need more input like this, to go that way.

> * If the tasklet has a single frame and it performs a python "return",
>   the caller of tasklet.run gets the return value.

What is the caller. What is the caller?
You might think that run() defines the caller. But run() is
an artificial thing at the moment, just there to make sure
that the spelled tasklet is run right now.
We might have to re-consider run(), if it should carry semantics
like being a real caller.
Again, I need this discussion on the mailing list!

> * There's a scheduler object with which tasklets can be registered.
>   scheduler.schedule(tasklet) will add tasklet to the list of tasklets
>   run by the scheduler.  scheduler.run() will call tasklet.run() to
>   execute the registered tasklets.

So you think that all the scheduling stuff should be local to
a scheduler object? Furthermore, do you want to have several
scheduler objects, maybe with different opinions/strategies
at the same time?
This would change things a lot, and it might make much sense,
at least it would make much noise. I need to know whether this
would be of general interest, then I might go for it.
If not, I'd like to keep Stackless as simple as possible.
(This is what I claimed for years, with little success :-)

> * We don't need to have stackless.schedule or stackless.run functions
>   anymore.  The user simply calls the run method on the scheduler.

Then I'd really need a definition of what run() should do.
Does it mean that that tasklet should run now? (Current truth)
Or, should it mean that that tasklet should run and return it's
value to the current caller, which is the tasklet that issued
the run() command? Guaranteed?
Other question: Would such behavior, provided it makes sense,
contradict the CSP paradigms?

Hey, I need input of the people with that special experience.

thanks so much --- chris

-- 
Christian Tismer             :^)   <mailto:tismer at stackless.com>
Mission Impossible 5oftware  :     Have a break! Take a ride on Python's
Johannes-Niemeyer-Weg 9a     :    *Starship* http://starship.python.net/
14109 Berlin                 :     PGP key -> http://wwwkeys.pgp.net/
work +49 30 89 09 53 34  home +49 30 802 86 56  mobile +49 173 24 18 776
PGP 0x57F3BF04       9064 F4E1 D754 C2FF 1619  305B C09C 5A3B 57F3 BF04
      whom do you want to sponsor today?   http://www.stackless.com/



_______________________________________________
Stackless mailing list
Stackless at stackless.com
http://www.stackless.com/mailman/listinfo/stackless