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

[DavidFCannock]

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

[tst]

The best place for these types of discussions is the AF group in the communities section of this site. You will also find some existing discussions on this topic there, including a fairly recent one (last couple of months) which went into this in some depth. I haven't read it too closely, but I think the bottom line was a reluctance to have something like this built-in for all actors, because the desired behavior is actor specific. There may have been some talk about adding some components to make it easier to do this and if that's the case, there may also be a branch which has this which you can check out of Github. Look at the group.

[DavidFCannock]

---

@tst wrote:

The best place for these types of discussions is the AF group in the communities section of this site. You will also find some existing discussions on this topic there, including a fairly recent one (last couple of months) which went into this in some depth. I haven't read it too closely, but I think the bottom line was a reluctance to have something like this built-in for all actors, because the desired behavior is actor specific. There may have been some talk about adding some components to make it easier to do this and if that's the case, there may also be a branch which has this which you can check out of Github. Look at the group.

---

Thanks, I've cross-posted it over there. I'll also search to see if I can find similar discussions.

> I haven't read it too closely, but I think the bottom line was a reluctance to have something like this built-in for all actors, because the desired behavior is actor specific.

That seems kind of odd. I don't have an expert grasp on Actor Framework yet, but my understanding is that you override Stop Core.vi to implement actor-specific deinitialisation logic. After that's executed, the framework will automatically send a Last Ack to the parent actor.

If that's correct, then surely all the actor-specific deinitialisation logic can be placed into the overridden Stop Core.vi and you could update the design of the framework to allow a parent actor to only stop running after it's received a Last Ack message from each nested actor? Since the parent actor would only need to wait on each Last Ack without caring what actual deinitialisation is required by the nested actors, it'd make this solution extremely general and reusable. Hopefully I'll come across one of these discussions which will clarify the limitations of this approach for me.

[tst]

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.

[DavidFCannock]

---

@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.