Send Directly from Actor A to B (not via caller)

[amitwadje]

Hi All,

I am new to actor framework and I am stuck at following point, It will be great if you could show me the way through.

What I did ?

I can send can receive to and from caller (using read caller’s Enqueuer).

I created a small example for that (attached)

Three actors

Main Actor core.vi  : This will launch ‘Actor A’ and ‘Actor B’

I can send Data from Actor A ---toà Main Actor ----to-à  Actor B (using Read caller’s Enqueuer).

What I wish to do?

What I can do is to send data from Actor A ---to---> Actor B directly.

How to get message Enqueuer if the caller is different?

How to use ‘Address Message.vi’ ?

Thank you for help.

[Oli_Wachno]

Well, your Main Actor "knows" the enqueuers of Actors A and B, so it can send them to the respective Actor in a message.

Using this enqueuer, both SubActors can communicate with each other... sweet as.

But be aware of the pros and cons of direct communication.

[amitwadje]

Hi Oli_Wachno,

Thank you for your reply. I tried this way more explained here as approch 2 (Sorry for duplicate post).

can you explain more about the pro's and con's ?

Thank you.

[Oli_Wachno]

Direct messaging between the Actors can introduce a lot of complexity to the application. The more Actors are communicating, the more side effects can occur due to the asynchronous message execution. In an uncontrolled enviroment, debugging will become an nightmare, if you don't put some clever methodologies in place.

Furthermore you increase coupling between the actors, if you don't use zero-coupling messages: Actors "talking" to each other will have to "know" each others message objects, which introduces dependencies. Which again might be ok for small applications. But speaking of complexer ones, the Actor's inherent modularity will suffer.

Reffering to your other post: my personal recommendation is to thouroughly learn OO with LabVIEW first. Otherwise, your success using the AF will be very limited.

[AristosQueue (NI)]

You have wandered into a philosophical discussion.

I will help you to do this thing that you ask, but I would like you to promise me that you'll at least think about NOT doing it. 🙂

You have Caller launching A and Caller launching B. In order to have A send directly to B, Caller has to send a message to A that includes B's enqueuer. This is Caller giving explicit permission for A to talk to B.

Now you know how to do it. I believe this to be a very bad idea. In my observation (and the reason I created the Actor Framework), such messages:

-- violate the encapsulation of functionality

-- mess with order of message delivery.

-- make debugging significantly harder.

Yes, it can decrease the amount of code you have to write, sometimes quite a bit, but I really, really, really believe that that is a false win when you pay the price on the back side of your project.

My contention -- and it is a contention that is disputed by other very reputable developers -- is that a well-designed actor in the AF should never need to talk to any actor except its caller and the nested actors that it launches. You can find various posts throughout the AF forum on this topic.

The right way to do this is to have A send messages to caller that are relevant to the relationship between Caller and A, and then have Caller decide, "Hey, you know what, that message I just got from A? I should tell B about that." And then Caller will send a message to B. It won't be the same message. It might not even be the same topic. It won't even mention A. Caller is the sole place in your code where the interaction between A and B are moderated. This, in the long term, makes it much easier to adjust the behavior of actors, to insert new layers of actors, and to control the states of actors as they receive different messages.

I know it is a limitation that will chafe as you're developing. I really believe that it is a happier thing than the pain of debugging on the backside, especially as code matures over time.

Go forth, developer! 🙂

[Daklu]

AristosQueue wrote:

I know it is a limitation that will chafe as you're developing. I really believe that it is a happier thing than the pain of debugging on the backside, especially as code matures over time.

Preach, brother.

For the past two years I've been detangling an application that makes extensive use of direct messaging.  It's built usiing more traditional methodologies instead of the AF, but the principle still applies.

[BillMe]

Well then, despite my attempts at defining logical, clear responsibilities for my actors, I hope I'm not the only one ending up with a number of messages that are just basically routed around the AF tree to their destination actor(s) keeping with the strict communication philosophy. It's important in those cases to document what's going on since the "routing" actors have no interest in the message being passed through. Two cases where this manifests itself for me: 1) The UI where user event information needs to make its way to the appropriate actor possibly three or four levels down and 2) when acquiring data from H/W where the data is needed by several different actors for different reasons. I could have used other IPC methods to "short circuit" the AF messaging in these cases, but I didn't. I wanted to stay with the recommendation and hopefully reap some benefits when my application is complete (almost there).

Bill

[AristosQueue (NI)]

BillMe wrote:

It's important in those cases to document what's going on since the "routing" actors have no interest in the message being passed through.

It does happen, but I encourage you to look at those "routing actors" and think more about whether they care or not. They might care and still not do anything to modify the message... a lot of those only ever develop special behaviors at shutdown/startup time or only when you start adding more advanced features. In other words, they always care, but they don't always have special behaviors. 🙂

BillMe wrote:

1) The UI where user event information needs to make its way to the appropriate actor possibly three or four levels down and

Right... let's look at this one. Consider a hypothetical automobile.

There's a console of buttons. There's a single Button actor for a button labeled "Drive Backward". When that button is pressed, the Button Actor sends a message "I've been hit"!

The Dashboard UI actor hears that message. It disables all the other controls. Then it sends a message to the Whole Automobile actor that says "Drive Backward X meters", where X is a distance to drive that is packaged into the message. Just sending "I've been hit" isn't going to be meaningful to the other actors. In this case, the Dashboard UI actor both responds to the message and relays a different message.

The next actor in line is the Whole Automobile actor. It receives that Drive Backward message. It sends two messages to other actors. The first is to the Lighting Manager: "Drive Backward X meters". The second is to the Motor actor: "Drive Backward X meters". Did the Whole Actor care about the message? Well, yes. Even though it just relayed the message, it made a decision to send it to the Lighting Manager and to the Motor. It did not send it to the Radio actor or to the Sunroof actor. The Dashboard UI did not know anything about the Motor or the Lighting Manager. In the future, there might be a new Rear Facing Camera actor that turns on when backing up... and the Dashboard UI would not be changed at all in this scenario.  In this case, the Whole Automobile actor cared about the message by choosing the routing. If you ever have a case where you've written one sibling and you are even thinking about the effect on the other sibling as you write the first one, I suggest you might have a problem of coding it too much for that domain. Something to think about.

So, my point is -- the receiving actor *always* cares. Sometimes it cares because it has stuff to do itself from the message in addition to relaying. Sometimes it needs to modify the message for a new domain. And sometimes it knows the thing that the message should be passed to. But it always cares.

BillMe wrote:
2) when acquiring data from H/W where the data is needed by several different actors for different reasons. I could have used other IPC methods to "short circuit" the AF messaging in these cases, but I didn't. I wanted to stay with the recommendation and hopefully reap some benefits when my application is complete (almost there).

This is one where the receiving actor is the thing that knows everyone who needs to receive it. Adding additional children shouldn't touch the actor that is generating the data. All the rules for who receives it is encoded in the actor that is distributing the information out.

[BillMe]

In that case, unlike most actors, mine are very caring and not the least bit selfish or egotistical.

[AristosQueue (NI)]

Your bleeding heart is a leaking abstraction! Your actors keep giving other actors fish instead of teaching them to fish for themselves... you will find that they grow dependent upon one another. Let the one decide to not send fish, or even a different kind of fish, and you will see them fall upon each other like wolves. Will you call them selfish later when they go on strike and refuse to work?

Written with joking tone but serious consideration... 🙂