Request: lose the "Caller-To-Actor" and "Actor-To-Caller" language

[AristosQueue (NI)]

Daklu wrote:

Given the target audience, I'm not at all convinced keeping subactors running after the calling actor has stopped is a use case you want to encourage with something so obvious as "Stop Nested Actor" boolean.  It's much simpler to define an actor tree as a system of actors that work as a unit and all stop together.

Generally true, but not universal enough (IMHO) to assert that all actor trees should work that way. The shutdown process for an actor tree may not be instantaneous. One client of the AF had a massive machine as one of its subsystems. The actor that represented the machine itself would get a Stop signal and would stop itself so the rest of the system could no longer send messages to it. Then all of its deeper layers would go into a shutdown sequence that would take several minutes. When the actor that represented the machine recieved Stop, it did not send a Stop message to its nested actors -- instead, it sent a "do cleanup process" message, and those nested actors would send themselves several more messages, and work within in each other to bring the machine fully to a halt.

We can do something to make it lots easier to do "stop means stop all nested also", but I'd still want an opt-out ability.

[AristosQueue (NI)]

Daklu wrote:

I'm talking about the difference between this...

<snip image/>

and this...

<snip image/>

Launching from the helper loop does not change the communication path at all. Just because Launch Actor is called in the helper loop does not mean that the communication is with the helper loop. Indeed, unless the programmer is doing something to provide the nested actor with some additional communications path (generally discouraged by AF), the only comm path that the nested actor has is back to the helper loop. Useful for firing off a nested actor that will do some subcomputation and when finished, posts its results back to its caller (which may or may not need to pass those to the helper loop).

Having said that, I'm kind of getting comfortable with the idea that you would send a message to yourself to launch the nested actor.

[Daklu]

AristosQueue wrote:

Generally true, but not universal enough (IMHO) to assert that all actor trees should work that way..

I'm not asserting all actor trees should work that way.  I'm asserting that's a good default behavior for actor trees.  The solution I provided implements autostop as the default behavior while providing subactors with the ability to opt-out if desired.

AristosQueue wrote:

Launching from the helper loop does not change the communication path at all.

Launching from a helper loop doesn't necessarily change the communication path, but it increases the chances an inexperienced user will end up with poor communication paths.  If the helper loop uses a message queue pair as its message transport mechanism, then it would be very easy for an inexperienced user to wire the helper loop's enqueuer into Launch Actor instead of the actor's enqueuer.  Here's the block diagram for Beeper.ActorCore from the example project I posted.

In this particular case I'm using a DVR to get data from the message handling loop to the helper loop.  However, with a bit more coding I (or another inexperienced AF user) could have set it up to use a message queue pair and implemented a message handling loop with a timeout wired into the Dequeue method.  If the helper loop launches a subactor, it's not hard to imagine how someone could accidentally insert the wrong enqueuer as the Actor-to-Caller enqueuer.

[Edit - After posting the image above I realized there is a significant mistake in the code--I put the Wait inside the IPE structure.  This can cause messages to get backed up in the message handling loop, which leads to all sorts of undesirable behavior and complicated solutions (like popping all the messages from the queue and figuring out which Beep and Period values we really want to use.)  Shame on me.  The solution to the problem is shown below.]

AristosQueue wrote:
Just because Launch Actor is called in the helper loop does not mean that the communication is with the helper loop.

You are correct--there are ways to launch an actor from one loop and have it be owned by another loop, just as there are ways to launch an actor from one actor but have it be owned by another actor.  I think having these abilities is good; however, given the target audience I believe these practices should be discouraged until the developer becomes more familiar with the principles of actors and tree-based messaging.  Launching from one loop (or actor) but giving ownership to another loop (or actor) is not that different from dynamically reassigning ownership.  Most of the time it adds needless complexity.  Just as the messaging topology is easier to understand when one follows the rule, "the launching actor is also the owning actor," it is also easier to understand when one follows the rule, "the launching loop is the owning loop."

Other than excessive launching time, I still haven't seen an argument for why a helper loop should launch a subactor.  I can think of lots of reasons why a helper loop would make a decision that a subactor needs to be launched, but none for why that launching should take place in the helper loop.

[Daklu]

FWIW I created a custom branch of the AF, implemented autostop by adding Launch Subactor and Stop Subactors methods, and modified my sample project to use the AF branch.  As before, search for "{AutoStop]" to see the implementation and how it's used.

[Daklu]

tst wrote:

I'm not sure that [static actors] should be something that's allowed, as having the framework expose its internals so that users can use them makes it more difficult to understand (and in fact it's possible that some of the existing VIs on the pallete, like enqueue and dequeue, should be removed.

While I think better support for static actors would be good, it's not just about interacting with static actors.  For the AF (or any framework/library) to be widely useful it needs to be able to interact with code that isn't part of the framework.  Enqueuers have to be exposed.  I believe dequeuers don't have to be exposed, but I think it makes more sense to keep it on the palette anyway.  The message queue pair is just another transport and it can be useful to allow developers to use it as such.

I would suggest that if communicating with non-actors is needed, then it should probably be limited to reporting something like last ack from the root, and then maybe there should be a special VI just for waiting on that.

Assuming you mean communicating with non Actor Framework actors should be limited, I disagree.  Trying to simplify the API by building a wall to keep out non AF code just makes the AF less useful overall.  It doesn't matter how simple the API is--if people can't do what they need to do they won't use it.

[AristosQueue (NI)]

I have posted an experimental fork of the AF that makes the changes requested in this thread.

https://decibel.ni.com/content/docs/DOC-34147

Please evaluate.