How do I get an actor to wait for its nested actors to stop running before stopping itself?

Question

I'm developing a series of projects that are based on the Actor Framework and my actor dependency hierarchy is starting to get some depth. One of the issues I'm facing now is making sure that each actor will only stop running (and signal this via a Last Ack to a higher-level actor or via a notification to non-AF code that launches it) once all of its nested actors have stopped running.
For instance, say I have a type of actor that handles communication with a microcontroller over USB - a USB Controller Actor. I might want to have an application-specific actor that launches USB Controller Actor to issue commands to the microcontroller. When shutting down, I want this top-level actor to send a Stop Msg to USB Controller Actor and then wait to receive a Last Ack back before sending a notification within a provided notifier to the non-AF application code, which can then finish shutting down completely.
I'm sure that having actors wait for all nested actors to shutdown before shutting down themselves is an extremely common requirement and I'm confident National Instruments have made it possible to handle that in a simple, elegant manner. I'm just struggling to figure out what that is.
The approaches I've experimented with are:
Creating a pseudo "Stop" message for an actor that won't actually stop it running straight away, but instruct it to stop all nested actors, wait for their Last Acks and then shut itself down by sending Stop Msg to itself. This isn't elegant because it means the client will be forced to fire off these pseudo stop messages instead of Stop Msg to certain actors.
Instantiating an internally-used notifier and overriding Stop Core.vi and Handle Last Ack Core.vi. The idea is that within Stop Core.vi, I send Stop Msg to each of the nested actors and then make it wait indefinitely on the internal notifier. Within Handle Last Ack Core.vi, I make it send a notification using this notifier which allows Stop Core.vi to continue and perform deinitialisation for the top-level actor itself. Figures 1 & 2 below show this approach. I wasn't confident that this would work since it assumed that it was possible for Stop Core.vi to execute and then Handle Last Ack Core.vi to concurrently execute some time after. These assumptions didn't hold and it didn't work. It would have been messy even if it had.
Overriding Stop Core.vi, making it send Stop Msg to each nested actor and then waiting for an arbitrarily long period of time (100ms, 200ms, etc.). What if a nested actor takes only 10ms to shut down? What if takes 400ms?
The figures below show how I implemented the second approach. Ignore the broken object wires - they only appear that way in the snippets.
Figure 1 - Stop Core.vi from the second approach
Figure 2 - Handle Last Ack Core.vi from the second approach

Answer 1

tst wrote:
It wasn't that hard to find - https://decibel.ni.com/content/thread/27138?tstart=0
But with dozens of posts, I have no intention of rereading it now.
Also, when crossposting, it's considered polite to add a link, so that people can see if the other thread has relevant replies.
Thanks. I've only read the first page for now but I find this interesting (I'm not sure how to format non-reply quotes, sorry):
 "AristosQueue wrote:
CaseyLamers1 wrote:
I think that this would be a nice addition. I think how a program stops is just as important as how it starts.
I think everyone who has worked on AF design agrees with this. Indeed, managing "Stop" was *the* thing that lead to the creation of the Actor Framework in the first place. The other issues (deadlock/hang avoidance and resource management) were secondary to just trying to get a clean shutdown.
CaseyLamers1 wrote:
I find the current code a bit lacking.
My concern would be that the mixing of a verified stop and a regular stop could create confusion and lead to people having trouble during editting and testing with the project ending up locked (due to VIs left running which did not shutting down).
Your concern is to some degree why no verified Stop exists in the AF already. We looked at each actor as an independent entity, and left it open to the programmer to add an additional managment layer for those applications that needed it. But over time, I have seen that particular management layer come up more often, which is why I am exploring the option."
So that gives one of the reasons why this hasn't already been implemented but also points out that it's something quite a lot of people want.
> Also, when crossposting, it's considered polite to add a link, so that people can see if the other thread has relevant replies.
Noted. Here's the discussion: https://decibel.ni.com/content/message/104983#104983
Edit: since there doesn't seem to be any NI-provided way of doing this yet, I suppose I'll try rolling my own at some point. The ideas posted in the discussion you linked seem pretty useful.