Application Instance Close

[GollumGTH]

In the comments for the application instance close event in the top level actor of the actor framework project template it says:

"So add any cleanup code that absolutely must happen here, such as resetting hardware. This event will fire no matter how the app instance shuts down"

A few questions regarding this:

1.  Would I be correct in saying that if the application is shutting down we cannot assume any other actors are running and so should not send any messages in this space?

2.  If there are multiple actors, each controlling some piece of hardware, should they each have an event structure with this event case to run code to put the hardware back into a safe state?

Thanks.

[stbe]

Hi GollumGTH,

ad 1: true, we cannot assume other actors are running, but if they are running, the reference to the message queue you keep should be valid - you may test for that

ad 2: the event structure "Application Instance Close" event will trigger in only one event structure, not in all (same issue with two event structures in one block diagram - you should never do that). I put hardware cleanup code in a derived instance of the stop core VI of the concerning actor - I think there's a comment too. If you follow the block diagram on the Actor::Actor Core, you will see that the Stop Core will always be called when the actor is shutting down.

edit: just checked my assumptions with a simple test case ... works (but I rather stay with one event structure per event) - thanks for pointing this out @AQ

-Benjamin

[AristosQueue (NI)]

I'm 99% sure that stbe's answer #2 is incorrect. All the event structures registered for a given event will fire when that event triggers, and there should be nothing special about App Instance Close in this respect.

The App Instance Close block is for restoring to the system any resources that need to be restored when your VI is being aborted by a shutdown. You only need to worry about the abortive case.

[GollumGTH]

So then going back to my original question, should each actor controlling a piece of hardware that might need to be put back in a safe state before the program closes put this code in this event case?  In other words, when the program is being aborted, is it safe to assume that the stop core VI will still be run in the normal fashion?

Also, in response to ad 1 from stbe, if the program is being aborted is it safe to assume that any messages will actually be completed once sent, even if the reference to the message queue was valid?

Lastly, would it be wise to just put a call to stop core in the Application Instance Close event of your top level actor?

I guess I just generally don't know much about how the OS handles shutting down my application in this case and would like to know the best method to leave everything in a safe state no matter how the software is stopped.

[stbe]

Unfortunately, if the program is aborted, it just stops!

That's why there is the "App Instance Close" event is used - seems to be some kind of a try-catch-finally construction that is (this time really) always called when the application instance (so your program) stops/aborts/closes.  You would need to test if this also is called if there is an error that makes your program crash (not using the AF error handler to shutdown the program - ie. using the Close LV primitive).

So back to your questions:

Concerning encapsulation, if you use an actor to control a dedicated piece of HW, you should access the HW only in this actor and provide an interface to work with via the message system of the actor framework.

The HW de-initialization (shutdown procedure) is better placed (sub-VIs keep the main block diagram understandable of course ) in the App Instance Close event - you can make one in the event structure of each actor (since all events will fire).

So, the Stop Core.vi will not run in the App Instance Close event - I overlooked this the first time in your question - but  we've AQ .

To #1:

IF the actor still is running, its message refnum is valid and the actor is waiting for messages:

If you use the message system shipped with LV 2012 (that one that uses the priority queue), any message that is sent and has a higher than or equal priority as the "Stop Message" (that might be sent by the caller) and is enqueued before the Stop Message will be completed (first in, first out).

IF the actor is NOT running, nothing will be completed.

I would not place a call of the Stop Core.vi into the App Instance Close event, because for the normal shutdown, it will be called twice then. I don't know what happens if you try to de-initialize your HW twice, but it will usually raise some error.

So, I try to summarize AQ's ideas within the AF:

* HW deinitialization code (or external - not LV) into the App Instance Close event of the corresponding actor (since it will be called regardless of the kind of shutdown)

* SW deinitialization (queues, references, ...) into the derived instance of the Stop Core (they are required to make your software shutdown properly in the standard (and standard error) case, but are not required in an abortive case)

Personally, I don't use the App Instance Close event though I use several Windows DLL that need to be properly deinitialized - the standard shutdown procedures using the error handler of the AF always worked for me. (Maybe I should also "fix" this since I got to understand the AF a bit better now).

However, I cannot think of an example right now (except of the already mentioned Quit LV primitive) that would make my program stop without using the AF error handler and is possible within my own LV programming style guides.

(I assume the App Instance Close event will NOT be triggered if LV crashes)