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

[AristosQueue (NI)]

I agree with drjdpowell's last post. I just don't know how far we can go in providing that abstraction.

[Brainstorms]

One of the problems with abstracting any given transition from State A to State B (not just shutting down) is that the real world isn't always co-operative:  Errors can (and do) occur -- for a variety of reasons (programming error, OS glitch, operator did something unexpected, external stimulus out of range, file is missing, instrument powered off, etc.).  Any of which can muck things up and make the state transition vary from impossible to inappropriate to "recoverable, but requires supervisory assistance". 

So, yes, I agree, too.  But any of the above can dash a neatly packaged abstraction.  (Crashing while adhering to principles is probably not what your customer expects.) 

Handling errors is no fun, and requires a premium-model crystal ball and a truckload of extra code to deal with properly.  But I still am of the opinion that cutting off the outside world once told to "begin shutdown transition" as a rule of thumb may not be the best course of action in general.  Again: This needs to be carefully designed, and not covered by the wave of an academic hand.  So I agree with you, too, AQ: It may not be possible to go very far in that abstraction, and it might turn out that the answers are (unfortunately) rather app-specific.

[drjdpowell]

Abstract away that which can be abstracted away, and not that which can’t.    I don’t think “shutdown” is a useful abstraction for a subsystem, except at the point where it no longer requires input from the rest of the system.  What you are talking about is the shutdown of a complex system.   That system shutdown might involve complex interactions with subsystems, but that should be before the subsystems are told to “shutdown”.  Sometimes that “shutdown” command may do little more that exit the loop, all actual cleanup work having already been down under supervision.  But in most applications of “actors” significant work will be doable in the shutdown logic (with errors handled locally).  In fact I don’t think any of my applications have required complex shutdown logic (they are mainly data collection apps, rather than equipment control).

[drjdpowell]

A better reply…

I think that you, Brainstorms, are using a poor mental abstraction.  That a subsystem is "shutting down" while it still needs to interact with the rest of the system.  Drop that abstraction.

[AristosQueue (NI)]

drjdpowell wrote:

I think that you, Brainstorms, are using a poor mental abstraction.  That a subsystem is "shutting down" while it still needs to interact with the rest of the system.  Drop that abstraction.

That is a better way to phrase the problem.

You can tell a component to "shut down" meaning "do a lot of back and forth with me to coordinate your shutdown with other components". Or you can tell a component to "shut down" meaning "you're done. Quit."

The latter is the equivalent of calling an object's destructor in other programming languages -- and destructors are not allowed to throw exceptions or report errors. They clean up their workspace and they are done. What I am contemplating is taking the existing Stop mechanism and making it so that it can do more destructor-like work from the viewpoint of its caller while doing more coordinated shutdown work for its nested actors, instead of today where Stop can only do destructor-like work for itself and then tell its nested actors to do their own isolated destructor-like work.

[Brainstorms]

Actually your first reply was better.

Your second reply reveals that  we're talking to two different issues, as pointed out by AQ.  I'm addressing the needs of a complex system that must transition state on the way to being able to have parts of it "quit", a process which I'm terming "shutting down".  You seem to be definining "shutdown" as AQ puts it: "you're done. Quit."

Separate the abstractions and I don't see any issue over the concepts being discussed.  My focus is along the lines of AQ's last paragraph, above.

[CaseyLamers1]

The more I think about this and see this thread continue, the more I think that the best you can do is have a good description of how one might go about the "Shutdown" of a complicated system. This is too concrete to solve in the abstract. Once the shutdown of the system is finished a "Quit the Program" process could be abstract, but at that point it might as well just be the hierarchy traversal that you have now.

So about the only thing I would say is included in the general case is some knowledge that you are in the process of the "Shutdown", however even then you may not want to exit the program when it is complete (a la the Windows shutting down even when you changed your mind example).

At this point I have to go back to "What is the motivation behind implementing a general stop verification?" My feeling is that it is because AF developers run there program in the Dev environment, issue a stop command, something doesn't stop, they are locked out of their project due to running VIs, they are forced to close the project and start over.

If this is a primary use case, then I suggest you add a way to issue a "Kill" command to all actors but allow the project to stay open. Additionally add something like Monitored Actor to see which "Bad Actors" are still running. Oh yeah, and make it work in RT too when deploying from the IDE; monitored actor needs PC.

[ian.yeager]

But why add something to the AF that is so very application specific. I’ve only done two projects using AF so perhaps my opinion doesn’t hold much weight, but, in those two projects “shutting down” occurred in such completely different ways that if there was something built into the AF that presented us with a more formalized manner in which we can handle shutting down a complex system at best I would’ve had to ignore it in one or both of them, and at worst I would’ve had to create work-arounds so that I could ignore it. Seems like the current AF provides a means to send a destructor type message. How you handle that message on the recipient side is up to the developer. If you need a way to ‘shut down’ a recipient prior to sending it the destructor message than it seems like something that the individual developer should be managing and not relying on a pretty bare framework to do.

[AristosQueue (NI)]

CaseyLamers1 wrote:

At this point I have to go back to "What is the motivation behind implementing a general stop verification?" My feeling is that it is because AF developers run there program in the Dev environment, issue a stop command, something doesn't stop, they are locked out of their project due to running VIs, they are forced to close the project and start over.

That's not even close to my motivation, Casey. 🙂

The motivation is entirely for the run time environment. Many users (including myself) keep asking for a device that abstracts its shutdown sequence. They want the Stop message to mean "do what you need to actually stop" so that the caller doesn't have to worry about picking the right Stop message for the right actor. For some simple actors, this is just "be done, and pass the message along to any nested actors." For more complex actors, there's more stop work to be done. Both need to be handled by the same message, but the existing Stop Core behavior is hard to override to create the effect of a clean stop.

[AristosQueue (NI)]

Important note: After a caller sends Stop to a nested actor, the caller should treat the nested actor as dead. There should be no further expectation of being able to send messages to the nested actor. The nested actor may respond with some status messages, but in general the only reply is Last Ack.

We are trying to figure out strictly how to restructure the innards of Stop Core to allow more easily the processing of additional messages in order to shut down.