Actor Design Cyclical Actions

[jhoehner]

Hi All!

I've been thinking a lot recently about actor based development and best practices (not necessarily limited to Actor Framework actors, but the general idea of creating separate processes that all have one job, modularity, yadda yadda, you get the picture).

Specifically I've been wondering about how a developer should set up their actor such that any cyclical action/method plays nice with other methods that the actor might need to accomplish. 

 

An example:

-I've developed an application that has one simple DAQ actor and a separate UI that sends commands to this actor. 

-The DAQ actor has a timeout case that it executes every 100ms or so along with a separate command API.

-This timeout contains a method that grabs some data from the hardware and then broadcasts that data via user event so the UI can display it.

-The UI calls another one of the DAQ actors commands which in turn has the DAQ actor execute a case that is different from it's cyclical case/method mentioned above

-The DAQ actor has to switch gears to execute the other command/method and then will return back to executing it's timeout case. 

 

I know that helper loops are an important concept when working with Actors, but they've only been described to me as a way to offload methods/actions that take the actor a long time to execute, not necessarily as a way to protect your cyclical/timeout method from delays.

Is it normal to have helper loops handle the cyclical actions/methods for an actor and have the main message handler worry about all the other commands it can receive? 

 

The frameworks I'm kind thinking about/applying this to are AF and DQMH, but I feel like this concept finds it's way into tons of different homebrew frameworks as well. 

 

How do you guys approach this problem? 

 

-John

[drjdpowell]

A short list of possible techniques:

1) Let the hardware do the timing.  Things like DAQmx or IMAQdx can provide Events, such as "FrameDone", and some hardware can provide buffered data in precise short periods (every 50ms, say) where you can just make your timeout 0ms, because waiting 50ms means nothing to your UI actions.

2) have a loop/actor send a message periodically.  In "Messenger Library" this actor is called "Metronome", and there is an AF component called I-forget-what that does similar.

3) send a time-delayed message to oneself; resending when it is handled. Also on Messenger Library and the AF.

4) Calculate the time till the action is next due, and use that as timeout (or just do the action if the remaining time is zero or negative). Recalculate after an other message/event.

Generally, I would advise one never use a fixed timeout value to schedule a periodic action.  With the above methods one can easily have multiple periodic actions occurring on different time scales without any interference (assuming all the actions are reasonably quick).