[Stackless] Modelling simulated time and granular interruptions

[Grant Olson]

> -----Original Message-----
> From: stackless-bounces at stackless.com [mailto:stackless-
> bounces at stackless.com] On Behalf Of stackless at kaishaku.org
> Sent: Monday, July 03, 2006 12:45 PM
> To: stackless at stackless.com
> Subject: [Stackless] Modelling simulated time and granular interruptions
> 
> 
> I am writing a non-realtime proof-of-concept simulation.
> 
> I have Actors. They perform actions which take a specific
> amount of time. The trouble is, Actors can be interrupted
> while performing an action and could cancel that action.
> 
> I would like to know how I should implement cancellation
> of actions with stackless. I see two obvious possibilities:
> 
> 1) Call the action function many times, with each call
>    representing a sub-second slice of time, my "tick".
> 
>     # for this example, it takes 1 tick to say 1 char
>     def say(self,ticks,s):
>       i = 0
>       while i!=ticks:
>         if i==len(s): break
>         print s[i],
>         i += 1
>       return ticks-i, s[i:]
> 
> 2) Call the action function once, but allow it to be
>    paused, resumed or cancelled. I am not sure how
>    this is done. Would I place interrupt possibilities
>    at many/key points in the function? Is there a
>    better way?
> 
>     # "event" can pause, resume, or cancel the action
>     def say(self,s):
>       i = 0
>       while i!=len(s):
>         print s[i],
>         i += 1
>         if ...event...: break;
> 
> 
> I imagine the 2nd method is better, but I am not sure
> how it should be implemented, particularly in my system.
> 
> However, I also imagine the first option is more elegant
> and understandable in the flow of things. This may be
> purely my imagination and lack of stackless experience.
> 
> I plan to have a 2 dozen actors, and plan to perform
> actions over a simulated period of 2 hours.
> 
> The integrity of the simulated time is important. I do not
> want an actor from the future interacting with another still
> living in the past simply because of the way the scheduling
> worked out. Some ideas have introduced that possibility. :p
> 
> I am looking for a great solution using stackless techniques.
> 
> --
>  kai
> 
> 


I would setup a channel for all of the actors to receive messages for each
TICK that gets issues, and some sort of counter actor that sends these ticks
to the rest of the actors.  The counter actor will work to synchronize
everything; no actor will receive the 'next' tick before all actors have got
the 'last' one.

I'm not exactly sure what you mean by pausing, resuming, and canceling? Are
you talking about waiting 10 ticks to do something and changing the action
handler, or actually removing tasklets from the scheduler queue and killing
them?

If it's the first, you can just maintain internal state in the actors, and
have the TICK channel accept alternate messages that account for these
interruptions and pauses.

Here's the way I did actors, with sample code:

http://members.verizon.net/olsongt/stackless/why_stackless.html#actors

-Grant


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