[Stackless] Realistic ticking and acting

[Grant Olson]

> 
> 
> I have written 7 different proof of concepts for a relatively simple idea.
> Each implementation has drawbacks. Today I wrote an 8th which does not use
> channels, and I felt much better about it, but it doesn't do what I want.
> 
> I feel the control flow is overly obscured and prone to programmer error.
> This is primarily the case with channels, but it looks like I need them.
> At times I've wondered why channels are not "considered harmful". ;-)
> 

Because sharing info between threads by message passing is considerably less
harmful than the 'traditional' shared-memory approach to concurrency:

http://lambda-the-ultimate.org/node/193

[That link gets a little academic, but sums things up]

> I want to know how I should model the following in stackless:
> 
> I have some actors and a timekeeper.
> 
>   1. The timekeeper ticks.
>   2. On each tick the actors will act.
>      They can start new actions or continue actions
>      started in previous ticks which are not yet complete.
>      They may partake in group actions, such as a fight.
>   3. All actors finish their slice of actions for this tick.
>   4. Go to step 1.
> 
> The actors do not necessarily know what actions they will perform.
> They have a queue, but they could be interrupted.
> 
> The actors can perform multiple distinct actions simultaneously,
> such as walking and talking. All my proof of concepts were improving
> until I decided I wanted multiple "simultaneous" actions per tick,
> at which point a second layer of channels destroyed the timeline
> and I just couldn't work out the flow well enough to fix it.
> So far I have stuck with schedule, run, send, and receive.
> 

...

> 
> Each technique I've tried so far has something wrong with it. Often I want
> to control where a tasklet goes in the scheduler, for example I might
> solve
> some implementations' problems by being able to insert the tasklet not at
> the end of the schedule list, but 1 before the end, so the ticker stays in
> the right place. These dilemmas and more plague my implementations, unless
> the implementation sacrifices a feature.
> 
> Does it sound like I should be using stackless for this?
> 
> If so, how should it be modelled?
> 

Your general approach seems right, but I'm wondering how your actors are
communicating with each other.  For example, what throws the ticker out of
wack? Is it when b attacks a for the first time?

Also, how did the second layer of channels you mention fit into the
equation? I think you may have been overcomplicating things.  You should be
able to do everything you want with one channel per actor, and sending the
message command to the channel:

("TICK")
("ATTACK", b)
("DIED", b)

And only adjust the actor's internal action duration counters when receiving
the ("TICK") message.  And maybe even do something like:

def messages(self):
    while 1:
        msg = self.channel.receive()
        if msg[0] == "TICK":
            # adjust counters
            self.ticker() 
        elif msg[0] == "ATTACK":
            # put 'fight' action in queue
            self.respond_to_attack()
        elif msg[0] == "DIED":
            # stop fighting and return to whatever was next in the queue
            # , unless you're really nasty
            self.respond_to_death()

This should keep the ticker in the right place in the scheduler.

-Grant


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