From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
09-10-2018 08:49 AM
Also, it's really important to notice that this isn't a Parent-to-Child relationship, it's a Caller-to-Nested relationship.
When building things with actors you typically only care to launch the actor classes at the bottom of your actor class hierarchy. These represent fully implemented functionality, parent actor types often have blank logic in virtual methods intended for overridden behavior further down the chain. When you launch an actors at the bottom of the class heirarchy it gets all the logic of that entire chain!
It's called Composition when actors launch nested actors, and it's a different axis of construction than parent-child relationships. The execution tree of the Root actor and all of it's requisite nested actors (and their nested actors), is a different tree than the class hierarchy!
09-10-2018 08:55 AM
@Taggart wrote:
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.
What would one of these "forwarded" or "pass along" messages look like? I hear people saying that a lot of messages for an actor is around 15 or so...to facilitate this sort of architecture, how does one implement this functionality without having messages whose purpose is "send this message received from actor C to actor B" or something like that?
09-10-2018 08:57 AM
@Craig_ wrote:
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?
Thanks for the food for thought...I feel like my code is a bunch of teenagers at a kegger now!
09-10-2018 08:58 AM - edited 09-10-2018 09:01 AM
@CanadaGuy wrote:
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?
The communication scheme in AF is designed for communication between Root Actor and Nested Actor (Read Caller Enqueuer) and Actor with itself (Read Self Enqueuer). AF follows the principle of secrecy. The enqueuer of a nested actor should only be known to the root actor. If You break the secrecy, a nested actor could shoot down another nested actor without knowledge of root.
The world is not always hierarchical. Sometimes giving up secrecy makes sense, but you should be aware of the consequences.
In your case, I would suggest the following structure: Define a root controller actor that starts other nested actors (UI, simulation, log) and manages communications due to AF standard. I guess the effort will be limited. At least that's my experience.
09-10-2018 09:46 AM
@p4keal wrote:
The world is not always hierarchical. Sometimes giving up secrecy makes sense, but you should be aware of the consequences.
In your case, I would suggest the following structure: Define a root controller actor that starts other nested actors (UI, simulation, log) and manages communications due to AF standard. I guess the effort will be limited. At least that's my experience.
I was thinking I would make the log actor enqueuer global, in the sense that all nested actors would receive a copy of it and be able to write to the log as needed. Since the logger wouldn't do anything else, there should be little to no delay holding up the log actor from updating/writing the log to disk.
Now if I wanted to avoid that scenario, what would it look like for a calculation actor, launched by the simulation actor, wants to send a message to the log actor? From my pov, it looks like a message from calculation to simulation, a message from simulation to root, and a message from root to log...?
09-10-2018 10:10 AM
The tree model is certainly recommended, but not enforced.
I agree, and this is how it should be. (Don't prevent users from violating best practices when they need to.)
My question was with the statement that having sibling actors communicate directly was the recommended way to do it. I would recommend people new to actor oriented programming stick to hierarchical messaging until they have enough experience to understand the potential problems of breaking that paradigm.
09-10-2018 10:13 AM
Perhaps the recommendation should be modified to include a few exceptions? I'm still very much a noob when it comes to AF, so tips, recommendations, etc. are things I cling to for life! 😛
09-10-2018 10:36 AM - edited 09-10-2018 10:37 AM
From my pov, it looks like a message from calculation to simulation, a message from simulation to root, and a message from root to log...?
Yep, exactly. Furthermore, the calculation actor would be sending some sort of status message up the tree. It's the root actor that decides that needs to be logged to disk.
I was thinking I would make the log actor enqueuer global, in the sense that all nested actors would receive a copy of it and be able to write to the log as needed. Since the logger wouldn't do anything else, there should be little to no delay holding up the log actor from updating/writing the log to disk.
If you are writing your actors correctly, there should be little to no delay in the messages getting to the logging actor through the tree.
Direct messaging (not following the
tree) is possible, but it increases coupling and can have unexpected side effects. It depends on your application and what kind of message you're sending. Data messages are fairly safe to send directly. Control messages should always follow the tree.
09-10-2018 10:45 AM
I see...I have been paying little to no attention to the purpose of a message (data or control), so it appears I need to start distinguishing between the two.
In the case of following the tree structure, I do understand how sharing enqueuers between various levels of actors would result in varying degrees of coupling. Earlier someone mentioned that the Evaporative Cooler example demonstrated the queue sharing (I think). Is there an example showing perhaps 2-3 nested levels of actors where the messaging is passed up and down the tree? I don't think I've seen one yet, and if I did, I didn't recognize it.
09-10-2018 11:58 AM
@Craig_ wrote:
Also, it's really important to notice that this isn't a Parent-to-Child relationship, it's a Caller-to-Nested relationship.
You are correct. Thanks for catching that. I did mean Caller-Nested.