08-04-2018 11:36 AM
I have a root actor that launches two nested actors (side by side in parallel, not cascaded). The root actor is a UI actor. The first nested actor is a logging actor, the second actor is a simulation actor. For messages from each callee to the caller actor, I'm using the abstract/child message approach so the nested actors are not dependent on the root actor.
How do I send a log message from the simulation actor to the logging actor? One method I thought would be to includes a user event in the root actor that will fire when a log message is received from the simulation actor, and forward it to the logging actor. The other thought I had was that I could initialize the logging actor first, get its enqueuer, then initialize the simulation actor with the logging enqueuer in place. Does this create some dependencies that I'm not aware of?
Solved! Go to Solution.
08-04-2018 12:17 PM
The second method (passing the enqueuer) is the standard way of doing it. Use abstract messages to avoid coupling.
08-04-2018 12:20 PM
@Taggart wrote:
The second method (passing the enqueuer) is the standard way of doing it. Use abstract messages to avoid coupling.
Nice! Thanks for the quick response. I think I see how it will play out, but perhaps I'm missing something.
What about dependencies or "race conditions" when it comes time to stop the actor? In this example, how could I make sure that the logging actor is the last one to stop (and able to process stop messages from the other actors)?
08-04-2018 01:28 PM
Don’t use auto stop. Stop your other loop and wait for it’s last ack before stopping the logger. Then shutdown your main actor.
08-04-2018 01:29 PM
That's a duh moment on my part. Thanks!
09-09-2018 01:33 PM
@Taggart wrote:
The second method (passing the enqueuer) is the standard way of doing it. Use abstract messages to avoid coupling.
Hey Sam, I haven't been around the AF community in several years. Is passing the queue so sibling actors can communicate directly really the standard way of doing it now? That directly violates the hierarchical messaging structure that used to be recommended for actor communications.
09-09-2018 07:23 PM
Dave,
Without opening up LabVIEW and looking, I'm 99% sure that technique is used in the Evaporative Cooler Example. If I recall correctly it is also taught in the class (which has only been around for a year or two). It is certainly what I do when I need to (and it seems to work well). Although like you I much prefer the hierarchical tree messaging structure. I think the key word in your last sentence is "recommended". The tree model is certainly recommended, but not enforced. There are some legitimate reasons to bypass it with of course some tradeoffs.
Sam
09-10-2018 08:30 AM
Pardon my ignorance, but can you clarify something for me?
Do I understand correctly that the hierarchical approach is one where you send/receive messages only between adjacent actors based on who launches who? Actor A launches actor B, and actor B launches actor C. A should communicate with C by sending a message through B. If A launches B and C, then B and C would communicate only through A?
09-10-2018 08:42 AM
You are definitely on the right track.
If you think of a tree model,
Sending messages up and down the tree, one level at a time, (ie. between parents and children) is the recommended way. ie. each node communicates with the node immediately above it or any of the nodes immediately below it.
Skipping generations (ie. grandparents to grandchildren) or sending messages across the tree (ie. between siblings, cousins, etc) breaks that model.
So if you want to stick with the recommended way and need to communicate with a sibling, then you would need to send it to the parent who would then pass it on to the sibling.
09-10-2018 08:43 AM
Yes, from a hierarchical standpoint actors should only communicate along caller to nested, or nested to caller communication lines.
This can make your actor subsystems more reusable (avoiding coupling to things outside of your immediate actor subsystem), and makes it easier to handle whether those actors are running or not. Look at the actor overrides of pre-launch init and and send last ack; these make it simple to know when nested actors successfully start and shutdown, but that information only goes to the calling actor.
If you want to send messages between non-related actors, all they need is the enqueuer for each other, but who facilitates giving this to them?