Nested Actor Launching via Message

[JW-JnJ]

I have a class of nested actors that can have drastically varying ways to set them up. My root actor will also need to nested launch them after it is already running. Is it a good idea to allow the user to create the nested actor object, do a "preinit", then send that (non-running) object to the root via message? The root actor would then launch and initialize.

I guess the other options is a root message per nested actor type with setup options built into it. I was shying away from this because the other option makes it a bit easier for other people to create children and send them in. The message option means they would have to alter my code every time they want to make a new child.

Any other ideas?

[p4keal · Accepted solution]

Hello Josh,

in my projects (LV2014) I launch nested actors via message quite often and it works fine.
I use nested actors among other things for settings dialogue. They are passive in root actor, till user has to change settings. The root actor receaves a message and starts a nested actor in a action vi. If user closes the dialog, root actor catchs the last state of dialog actor in Handle Last Ack.vi and actualise the object in his class cluster. The difference to Your question is that I don't send actor object inside a message, but it is also possible, You can see that e.g. in Last Ack Msg.

[AristosQueue (NI)]

---

@JW-JnJ wrote:

Is it a good idea to allow the user to create the nested actor object, do a "preinit", then send that (non-running) object to the root via message?

---

Just to follow on to the previous well-written answer -- yes, this is fine and is an intended use case of the AF. The AF comes with a built-in message for doing this (Launch Nested Actor Msg).

[AristosQueue (NI)]

Important note: Having actor A tell actor B, "Here's an actor C that I think you should launch as your own nested child," creates a lot of coupling between systems and makes a lot of assumptions between actors. Although the AF supports this, users have often found that it is better for actor A to pass the data needed for actor C to actor B and then let actor B decide how to handle that data -- actor B might not use an actor C at all and might do all the work itself, for example. Or be refactored to split the task into actors C and D. Or something more complicated. The point is, it's a feature that I put into the AF that does work but that, in retrospect, I probably should have not encouraged within the framework itself... the use cases for it are far more limited in practice than I expected.

[JW-JnJ]

---

@AristosQueue (NI) wrote:

Important note: Having actor A tell actor B, "Here's an actor C that I think you should launch as your own nested child," creates a lot of coupling between systems and makes a lot of assumptions between actors. Although the AF supports this, users have often found that it is better for actor A to pass the data needed for actor C to actor B and then let actor B decide how to handle that data -- actor B might not use an actor C at all and might do all the work itself, for example. Or be refactored to split the task into actors C and D. Or something more complicated. The point is, it's a feature that I put into the AF that does work but that, in retrospect, I probably should have not encouraged within the framework itself... the use cases for it are far more limited in practice than I expected.

---

Yeah, I got the feeling this was far from the standard practice.

I guess I'll get a bit more into the details because I get the feeling the "100ft level" isn't doing me any favors.

The "root" actor is essentially a state machine. He owns a communication actor, and a parser actor who feed the root information to track changes. There are a lot of different pieces of data that could potentially come out of this system (data/states/etc). Now I'm designing this root as a library that will hopefully be used by multiple other coders and architectures. So my conundrum was "How do I make it easy to get the data via QMH, QSM, files, localhost UDP, etc and only provide what a coder needs?".

I created an output actor class. A parent class actor that has all of the abstract message targets (Do.vi) for all of the various data streams and an easy way to initialize/subscribe to those various data streams. The children of this output actor can just override what happens when the data is received and send it to the final destination (QMH, UDP, etc). They are only coupled in one direction because they can't really command the root to do much of anything. Each output actor handed to the root to launch would just be a child of this output type. I was hoping this would allow people to create output children without me having to create a special messages for each and have to roll the changes into my library.

It did feel against the architecture to me, hence the question. I feel like I have to thank you yet again for the detailed response and corrections.

[p4keal]

In fact, there is a built-in message for it in AF 🙂 Because Launch Nested Actor.msg is private, and thus is little relevant for me as an AF user, I have pushed it out of my active memory ...

The approach of adding actors to start in a message is, in my opinion, well suited for applications in which a root actor starts other preconfigured actors, without knowing how their configuration takes place, even without knowledge that kind of actors they are.  Examples of this would be an object manager or an object monitor.

I think one retains all the freedoms, if one instead to extract the data from the actor C and to send them to the actor B, sends the whole actor C. If the particular application requires it to start the actors D and E instead of the actor C, the user can still do so. But you have the advantage that you do not need to maintain additional data structures that may become inconsistent with Actor C and user applications. In addition you keep all the advantages of LVOOP. For me it was an important realization that one can treat actors like passive LVOOP objects as long as they are not started. On the other hand, since I've known and loved AF, I inherit almost all my classes from Actor.lvclass instead of Object.lvclass.