I'm thinking of formalizing verification of the Stop message in next rev of AF

[Oli_Wachno]

I feared you'd say so 🙂

[dsavir]

Hi,

If this is still relevant, I take it back A built in verified stop would be useful. However, insted of a "write must verify stop" I would rather have a message "send verified stop" in addition to the regular "send normal stop". Is that possible?

Thanks,

Danielle

[AristosQueue (NI)]

dsavir wrote:

If this is still relevant, I take it back A built in verified stop would be useful. However, insted of a "write must verify stop" I would rather have a message "send verified stop" in addition to the regular "send normal stop". Is that possible?

Yes, that's an alternate approach, but that approach requires callers to know to send Verified Stop, whereas the other solution lets the actor handle it as an internal issue. A nested actor should be opaque to its callers -- the caller shouldn't care whether its nested actor has its own nested actors nor how many such nested actors exist. That's an internal bit of knowledge. So from my perspective, we want callers to be able to send Stop -- the same Stop -- to all nested actors and have each nested actor decide what that means for themselves.

[StevenHowell_XOM]

AristosQueue wrote:

the same Stop -- to all nested actors and have each nested actor decide what that means for themselves.

AH HA! Now that makes sense, so if a caller sends a shutdown to all its nested actors and say one of the nested actors needs to run something before it shuts down, you would override Stop Core in the nested until a specific action or state is completed and then it can shut down? That way you wouldnt have a nested actor not completing some of its clean up code or a current process, but you can be guaranteed that once it has done what it needs to do it will shut down?

[AristosQueue (NI)]

StevenHowell_XOM wrote:

AH HA! Now that makes sense, so if a caller sends a shutdown to all its nested actors and say one of the nested actors needs to run something before it shuts down, you would override Stop Core in the nested until a specific action or state is completed and then it can shut down? That way you wouldnt have a nested actor not completing some of its clean up code or a current process, but you can be guaranteed that once it has done what it needs to do it will shut down?

You have the right idea, but, unfortunately, it cannot be achieved just by overriding Stop Core. Consider this case: You send Stop to an actor representing some complex bit of hardware like a digging machine. To bring itself to a stop, it has to move itself to some sort of storage position. Doing this move involves messaging many of its subactors, waiting for the subactor to reply with "ok, I did that" and then sending the next instruction to a different subactor. In other words, the digging machine actor is in its "I am stopping" state but still has to be able to receive and respond to a wide range of messages while it finishes its work. While in this state, all messages coming in from callers or other actors (if you've shared the queue around) should be rejected as "too late, I'm already in the process of stopping." Rejection means either ignoring them or sending some sort of error message reply.

That means you have to somehow know which message types are ok during the shutdown process and which are not.

The most obvious solution involves a VI that does type testing on the incoming message to check its type is acceptable. That's both slow and a nasty maintenance burden.

Another way that I've heard suggested to achieve this is for an actor to send a message to its nested actors saying, "Here's a new queue... use this to talk to me instead of the old one." Then close the old queue. Now the only actors who can message you is your own nested actors, so you assume that they'll only send you messages that are valid during shutdown because you've told them "you're now shutting down, too." Obviously, this would have to be baked into the Actor Framework since the caller queue is private data that no actor is allowed to modify.

There's other solutions as well that would need to be explored.

[StevenHowell_XOM]

Thanks for that information, makes perfect sense. Timing is EVERYTHING! 😃

[drjdpowell]

AristosQueue wrote:

Another way that I've heard suggested to achieve this is for an actor to send a message to its nested actors saying, "Here's a new queue... use this to talk to me instead of the old one." Then close the old queue.

Side note: if one uses User Events to pass messages instead of a Queue, then one can have more than one User Event, each with a separate registration.   Use one as a "Public" or "From Caller" message channel, and the second as a "Private" or "From Nested" channel.  On receiving stop, kill the Public registration, dropping all remaining messages, but keep handling the Private one open till shutdown is complete.

[AristosQueue (NI)]

True. But you lose all of the priority queue aspects when you do that. Priority messaging is the major reason the queues are used in the AF. I don't know of any way to apply priority ordering to user events to the degree that AF would need to operate correctly.

[AristosQueue (NI)]

What is sort of needed is an N pipes that merge into a single fat pipe, and at a particular moment, you can shut off some subset of the N pipes. The fat pipe is ordered and then fed into an event structure.

*** I say "somewhat" because all that mechanism is going to slow down the flow of messages, and I know that pipe speed can quickly become a problem in actor systems.

[Brainstorms]

Another way to implement this is with the State Actor pattern: Swap the Actor with a "shutting down state" version once the shutdown phase begins.  That way you avoid having to put  special "is shutting down" code in every handler VI.

However, there's a bigger issue that's not solved by any of these: The digging machine actor is in its "I am stopping" state, moving itself to some sort of storage location/position, and has cut off receiving messages from its superiors.  A child crawls into the storage location, and the system detects this -- but can no longer message the digging machine actor to abort this action.  No bueno.

In other words, there needs to be a means of normal messaging, subordinates-only messaging, and also executive messaging.  Even while shutting down, there needs to be a two-way communication to some over-arching executive actor that oversees and can influence the shutdown process, even while "normal operations" messaging is shut off (due to shut down).

Lastly, I'm concerned about deadlocks given the above discussions if a Verified Shutdown gets implemented as what is effectively a "Send Message and Wait for Response" coupling.

I'll join in the requests for LV to add a VI Server interface to list/track/control headless VIs running in the background, plus a button on the IDE to kill all running VIs.