Motivation for Handle Last Ack Core?

[George Gatling]

I'm digging deeper and deeper into the Actor Framework, and I can't figure the motivation for a VI named "Handle Last Ack" in private scope that does nothing but call "Handle Last Ack Core" in protected scope.  Could someone help me understand the benefit this provides?

[CaseyLamers1]

A couple of answers.

First a "Last Ack" is a message that an actor sends to the actor that launched it when that actor stops.

Handle Last Ack is private and can only be called within Actor.lvclass methods, not a child actor. This makes it so that it can be used in the template method for dealing with the receipt of a Last Ack message from a stopping actor. In other words it is called when/where it is expected as designed by Stephen/NI.

Handle Last Ack Core is protected as it is dynamic dispatch and can be implemented in any child actor to impart behavior. So you can add behavior that NI didn't want to force upon you (nor could they guess).

The use case for Handle Last Ack (and Core) is when you want an actor to do something other than stop when one of its nested actors sends a last ack. For example, you have an actor that you launch and you expect to stop itself, but you don't want the actor that launched it to be stopped. So, actors that launch other actors with limited lifetimes. Another use case is when you want to implement a controlled shutdown sequence.

Casey

[KuGr]

To add to what Casey said, the technique of a private framework method calling a protected dynamic dispatch method allows a framework to guarantee operations to occur before and/or after the dynamic dispatch call.

Handle Last Ack Core is not required to be overridden and, if overridden, not required to call the parent implementation.  So the private Handle Last Ack can do whatever it needs before and after the override.

In the current incarnation of Actor Framework, there is nothing to do, but lets say in the future that the AF keeps track of launched actors.  Well, now it is pretty straight forward to implement without changing the API of the framework.  AF can handle the cleanup of whatever it used to 'remember' the launched actor after calling Handle Last Ack Core.

Hope this helps.

Kurt

[CaseyLamers1]

In 2014 stop core can/will stop nested actors if you use "Launch Nested Actor" and you don't choose not have them stopped automatically.

Casey

[George Gatling]

I was perplexed because Handle Last Ack didn't actually do anything but

call the Core. That the pattern was used for future expansion makes a lot

of sense. I've been wondering about something similar in my own code. I

have an actor "Periodic Task" that sends a simple message (Periodic

Task.vi) to itself regularly. I have a child of it "Hardware Poller" that

overrides periodic task.vi and has a "Poll Hardware.vi" subvi inside the

override. Any children of "Hardware Poller" should only ever override

"Poll Hardware.vi" but never "Periodic Task.vi", for reasons the same

reasons as this Last Ack discussion. Is there a way block children of

"Hardware Poller" from overriding "Periodic Task.vi"?

[CaseyLamers1]

You could make it private, or static dispatch.

[George Gatling]

If I make "Periodic Task.vi" private or static dispatch then Hardware Poller cannot override it.  If I make it protected scope, then Hardware Poller AND its children can override "Periodic Task.vi".  Is there a way to make it so that some child class can override one of it's ancestors methods and also make it so that the next generation of children cannot override that method?

[KALee]

I have implemented this once because I wanted to grab the state of the sub-actor which just shut down. In my case, I was shutting down a sub-actor, but I wanted to start another fresh sub-actor with some of the state data from the old one which was just shut down. Handle Last Ack Core let me get to that state data.