03-31-2020 01:44 PM
I am new to AF and I have a few questions about actor enqueuers that I was hoping to gets some clarification on:
1.) Is an actor's self-enqueuer (returned by Read Self Enqueuer.vi) the same as the enqueuer for the actor that it's caller uses to send it's message? If they are different, what is the difference? Can an actor send it's self-enqueuer to another actor to get reply messages? Is this practice frowned upon?
2.) If a callee sends a message to it's caller and wants some kind of reply, how can the caller know which of it's callee actors sent it that message? It is up to the callee to send some kind of identifier in the message?
Essentially, I want to set up a publish/subscribe setup where callee actors send data request messages to the caller and then the caller tells other callee's to send their data to other callee actors directly. Since the caller knows all the enqueuers of it's callees that shouldn't be difficult, but how does it know which callee just sent it a "data request msg"? Alternatively, the callees could send their self-enqueuer with the data request and the caller can send that on to the callee that has the requested data.
This seems like it should fit right into the AF wheel house but I'm having trouble tracking down the best solution. Any help would be appreciated, even if it's a link to another forum post I may have missed.
Solved! Go to Solution.
03-31-2020 01:52 PM
The AF instructions that ship with LabVIEW directly address these points. Have you seen it? I don't mind clarifying, but I want to make sure you've seen that document.
If not: Go to "Create Project" and pick the Actor Framework template. Create the new project from that template. In the new project's documentation folder, you'll find an HTML file that has the details.
> Essentially, I want to set up a publish/subscribe setup where callee actors send
> data request messages to the caller and then the caller tells other callee's to
> send their data to other callee actors directly
Why do you want this? Here's my most recent post discouraging this idea. Yes, you can do it. Yes, people have done it successfully. But AF does discourage it because...
03-31-2020 01:58 PM
I will answer one question right off the bat just because it may not be clear in the HTML file:
> 2.) If a callee sends a message to it's caller and wants some kind of reply, how
> can the caller know which of it's callee actors sent it that message? It is up to
> the callee to send some kind of identifier in the message?
Yes, it is up to the callee to put that info into the message to caller. You can just use the enqueuer as an ID, which makes it both easy to send a response and to ID which nested actor sent the message (because the caller launched all the nesteds and thus can maintain a list or lookup table of info about the nesteds).
Sending your enqueuer to your own caller or to your own nesteds doesn't violate any design intents of the AF because your caller and your nesteds already have that refnum. Sending *someone else's* enqueuer to *anyone else* does violate the design intents. You can do it but, as I say in that other thread, most designs are improved by *not* doing it. 🙂
The AF does not itself provide the signing facility for return messages. We've talked about adding some sort of message for that, but every use case has been sufficiently specialized that we haven't really come up with a generic tooling for it. We don't want to make it a part of every message for a long list of reasons.
03-31-2020 02:42 PM
Thanks for the reference to the html, I knew that self-enqueuer/enqueuer question had to be answered somewhere.
Just a final clarification on that: So if a caller compares it's enqueuer reference it has for a callee to the "self-enqueuer" reference sent from the callee they will be identical?
Yes, I have read much of what you have written in regards to keeping to the actor tree with messaging (including the recent post) and I haven't ruled that out. My application is such that I intend to have some input actors collecting data from hardware, controller actors using data for control purposes, and output actors outputting the data for collection or commands. All actors are callees of a master caller actor that spins up and shuts down actors as needed and does the publish/subscribe duties. My intention was to have special "data messages" for sending data between callee actors, all being directed to do so by the master. All other messaging would be restricted to going through the master, staying within the tree. Alternatively, I could have the master accumulate all the data from callees and send it out to other callees as needed. The later seems more cumbersome to me, when each actor could just send out all the data to other actors when it gets updated. After reading much of what you wrote, I was feeling since I am restricting the peer-peer messaging to "data messages" I would be avoiding much of the potential pit-falls. But I'm open to being convinced otherwise.
03-31-2020 03:36 PM
> So if a caller compares it's enqueuer reference it has for a callee to the
> "self-enqueuer" reference sent from the callee they will be identical?
As for the rest, it's your application, and I certainly don't have enough data to say definitively, "This way is better." I only think -- with good evidence -- that it is better. But it is your call. And, if you have enough staff to build your application twice and compare the results, I'd appreciate the experiment. (Why can I never get managers to take me up on that? It's for science, people! Pure knowledge trumps profit, right?!)
03-31-2020 03:48 PM
If by staff, you mean me, myself, and I. I might have enough time to build both applications if this COVID-19 telework situation goes on long enough. More likely, I'll only build the 2nd one if the 1st one fails miserably.
Thanks for your help. If I come up with some concrete evidence that one way turns out to be better, I'll let you know.
03-31-2020 04:45 PM
I might have enough time to build both applications if this COVID-19 telework situation goes on long enough.
You are not the first to note this sudden boom in available time to do nothing but computer work absent distractions. Same thing happened during the 2008 financial crisis. Apparently the only way to advance computer science is with a severe threat to the social order that drives everyone indoors. That is a very depressing notion. Have you played the video game Portal? That path ends badly!
Joking aside, I'm honestly unsure how to ever really get more research into this modeling. Small scale test apps don't really cut it for testing real-world behaviors.