Actor Framework Discussions

cancel
Showing results for 
Search instead for 
Did you mean: 

Synchrounous Reply Message Example

Solved!
Go to solution

All the Do methods I can recall just invoke an actor method. The only method indicators used are the actor object and error indicators. When I have an abstract message implementation, I usually rearrange the data so the actor method takes in one cluster with both the abstract message attributes and the implementation-specific data.

0 Kudos
Message 21 of 24
(1,221 Views)

I searched previous conversations, and I think we are repeating ourselves.  Smiley Happy

Message 22 of 24
(1,218 Views)

PrimaryKey ha scritto:

The point behind actors is that each actor is responsible for himself. In your situation the Main should not care if the DAQ has successfully initialized because its the responsibility of the DAQ to take care of stuff like that. The only situation when DAQ should communicate its status to the Main is then it dies. Those situations you can handle with last ack. Other than that the Main should send jobs and not care what is the state of DAQ. The moment you start to mix responsibilities you loose the benefit of AF. 

DAQ should retry Initializing for N times before crashing and returning Last Ack to the Main caller.

The reason why Reply msgs should not be used is exactly this. When you use Reply msgs you introduce mixing of responsibilities. With generic events and subscriber/publisher this is mitigate with zero coupling.


Sorry but I can't understand your point.

A "DAQ actor" must give response to it's "caller", so it's coupled, and it's fine, there is nothing wrong with it.

The DAQ-actor is responsible of DAQ hw management (so it has, let's say, the classic methods "open/init", "read sample", "close/quit"), but it's totally useless on it's own.

 

I don't know why you are all hyped with "uncloupling things".

 

The question was legit, you didn't answer and provided an opinionated solution.

 

In software, KISS is better than "over engineered", and "uncoupling everything from everything" is quite bad 99%. Uncoupling is just plain wrong when you don't have to "extend" or create bases, which is 99% of time, becuase we have small problems.

0 Kudos
Message 23 of 24
(1,196 Views)

In the time since I originally wrote about my DAQ actor question, I've found a way to do what I want without needing a reply message. Though I still think having the ability to reply would be nice, I'll admit I'm not experienced enough to understand the nuances. I've learned that Pre Launch Init was the synchronous, blocking initialization function I'd been looking for.

 

My original function was to have a DAQ routine that ran as its own state machine, with your standard "Uninitialized", "Idle", "Running", etc. states. In trying to implement this as an actor, I was trying to keep the same pattern, until I realized I didn't actually need to have the ability for the actor itself to idle or stop or start the DAQ process.

 

What I have now is actually a bit simpler, and I think a slightly easier to use solution. My initialization and initial parameter check is now done in Pre Launch Init, which is a blocking function that will return initialization errors when the actor launches. It's a way to have a single synchronous startup sequence. My intent with my original reply message was to let Main know if DAQ initialized its resources properly, and by doing that in Pre Launch Init, Main will see the Initialization error when it tries to call the actor. The DAQ actor then shifts immediately into "Output data" mode, and when it needs to stop I send it a regular Stop message, which deinitializes everything and shuts down the actor. When I need to output more data, I just start up the actor again. My original goal was to just start the DAQ actor once at the beginning of the program, and have it start and stop a DAQ task. I realized I didn't gain any useful functionality in this mode, so I took out its full internal state machine that allowed for starting/stopping/pausing/etc and replaced it with just what I needed to run.

 

I realized the only synchronous behavior I needed was for the Initialization state, and I didn't need blocking any other times. This way works, and is actually much simpler than my original implementation, and I think it's a better solution for my particular problem.

Message 24 of 24
(1,189 Views)