How the Root Actor should best monitor sub-actor receive queues, another newbie question

[MartinMcD]

Hello there,

Given everyone has been so helpful with my other question I have another related to the same application, I thought it made better sense in a separate thread.

In my currently-non-AF-app I have what I call my 'system mediator' and all messages between sub-modules/actors go through that. I suppose we would call it the root actor.

All my messages are user events so it makes it really easy - my mediator is just an event structure in a while loop and it sits there doing nothing most of the time, handling messages as they come in.  Everything is async.

My question is, if I move over to the queue-driven AF, then if my understanding is correct (and it rarely is) then this mediator/root-actor is going to have to get more complicated in order for it to monitor the receive queues of all the actors.  Rather than sitting doing nothing waiting for events to come in I will have to either set a very short timeout and keep polling the dequeue methods, or have each dequeue method in a separate loop for each of the n actors.

Before I plough on with the first option, or whilst I do so, I just wanted to check if I'm tackling it the right way or not.

Thank you,

Martin

[lukepike]

If a message is sent to an actor, no one else can intercept it. The send queue that is used to send messages to actors does not expose a dequeue method, so only the actor associated with the send queue will recieve the message. Instead, a message can be sent to the root actor which then sends an appropiate message to one or more sub-actors. This means that sub-actors must be aware of the root actor to send the appropiate message. There are a few ideas to reduce this coupling in the Using the Actor Framework in LabVIEW PDF.

Luke

[komorbela]

Hi Martin,

Lukepike basically answered your question, so you need to send messages to the Root actor and it will react accordingly (for example send the data further to another sub-actor using the sub-actor's input message). Your actor waits for message in the Actor Core, so you don't have to collect the messages. You just should have a method in the actor's class that handles that message.

To give you one option how to decouple the sub-actors from the Root actor, read my comment where I describe a possible implementation. The message maker what I propose in this comment is actualy not beeing done (by me), so don't ask for it

[MartinMcD]

Thank you for the help.  When I create an actor I use the 'Obtain Msg Queue Pair' so I was assuming my root actor would end up with multiple msg queues to monitor for each of the sub-actors directly below it. 

However, am I corrent then tht I should just a single queue ref to each of these sub-actors and then handle all the messages in the one Actor Core?  My current user-event implementation allows me to separate out messages from different sub-systems so I guess I was trying to hold on to that.

Thanks,

Martin

[lukepike · Accepted solution]

It sounds like your root actor is not actually a subclass of Actor, but a VI that uses the Msg Queue Pair to launch other actors. This gives you one recieve queue that the sub actors send messages to their caller on and multiple send queues that each sub actor listens on. The problem with this is that because the root VI is not an actor, it can't do anything with the messages it might recieve from the sub actors.

I typically have a main VI that launches a single main (or root) actor. The main VI can either stick around until the main actor shuts down or terminate once the main actor is running. Then the main actor launches the sub actors when needed, giving each one it's send queue to "Launch Actor.vi". The output of that VI is the send queue to the sub actor, which you can store in the main actor's private data. Sub actors then send messages to their caller using "Get Queue for Sending to Caller.vi". The main actor recieves the message and determines what messages to send (if any) to other sub actors.

The thing to remember is that messages are created for paticular actors, because they must typecast the generic actor object to a specific actor in order to call that actor's methods. This means that sending a message to an actor requires that you know what actor it is. Komorbela's linked comment shows one way of getting around this by creating a generic "template" message that the sub actor knows about and having the root actor subclass that message so it can call the root actor's methods. The only rub is that you have to pass this specific message subclass to the sub actor so that it uses the correct message class.

I hope this is somewhat helpful to you, this stuff can be sometimes hard to understand when starting out; I know it was/is for me anyway.

Luke

[MartinMcD]

It sounds like your root actor is not actually a subclass of Actor, but a VI that uses the Msg Queue Pair to launch other actors...The problem with this is that because the root VI is not an actor, it can't do anything with the messages it might recieve from the sub actors.

Yes, that's exactly the situation I'm in and the cause of my confusion.  I see now that this needs to be an actor, thank you for making it clear to me.  I have a splash screen which I can use to launch this root actor.  Slowly it is all beginning to make sense, thank you...

[lukepike]

No problem, glad I was able to help. Good luck with your project!

Luke