[Stackless] Make the Stackless Scheduler Your Friend Re: Realistic ticking and acting

[stackless at kaishaku.org]

> As Grant pointed out, the Stackless Scheduler uses a
> simple round-robin algorithm. Based on what you said,
> I would suggest that a round correponds to a 'tick.'

That would be great if true and it is true of a loop
using generators, but in Stackless once you .send
you have subjected your tasklets to another round.
You will hit the ticker prematurely when you .send
unless you fix it all with more sends. This would
be simulating generators yielding to caller I think.

So far I have not been able to fix it all with more
sends, but I am working on it. It's just difficult
to understand, because I will have to take care of
every tasklet in the round-robin list except the
ticker, because any one in the list left unhandled
will cause the ticker to execute next, prematurely.

It seems to me any task in the schedule list which
needs to .send is going to cause a major annoyance
when one of the tasklets in the schedule list is a
ticker that should only execute when all main tasks
say so, because once you .send from a main task it is
scheduled after the tick. Repeating what I said above.

I think I can probably do simpler things using the
stackless scheduler without problems, but doing
specifically what I want seems notably difficult.

> Kai, I would suggest that rather than fighting
> Stackless by trying to break up actions with a
> pseudo-scheduler, I would sooner control the robot's
> world view and ability to act. Say a robot begins an
> action, say THINKING at time t. The robot bases its
> computation on the environment(t). Then the robot has
> finished thinking, its next computation is based on at
> environment (t+compute_time)
>
> Another result of this approach is rather than
> building a scheduler on top of a scheduler, you can
> now focus more closely on the game logic.

My desired system specifies a "tick" as the smallest
unit of time. I cannot represent infinity and true
concurrency, so I must use a tick. In representing
realistic concurrency, actions are performed over
multiple ticks and interruptions can occur on tick
boundaries. This is my granular concurrency.

Most solutions I am being shown seem to forget this.

What I can do is forget generators and sends and
simply make my action functions return after a tick,
executing a fraction of their work and updating the
appropriate state for the object according to the
partially completed task. I am trying to avoid this
with Stackless, because I think that's the point.

> class Actor(object):
>    def execute(self):
>       while(some_condition):
>           if (not queue.empty()):
>              action = queue.pop() 
>              action(game.getWorldState(action, self)
>              schedule()
>           else:
>              break

Your code doesn't allow multiple non-conflicting actions
per tick unless, as mentioned above, I .send from every
top level tasklet. (afaik, of course)
 
> Also look at the Nancy Lynch solutions using
> synchronisers in her book "Distributed Algorithms",
> chapter 16. All these use message passing.

Writing my own scheduler, or .send()-only structure
appears to be the best/only way to do what I want
with stackless.

I think if channels returned controlled to the caller
when blocked I would have a much easier time with this.

-- 
 kai


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