Cleanup after Pre Launch Init?

[St3ve]

Hi All,

I may be missing something but... <Pre Launch Init.vi> is recommended as a place to create references with the same lifespan as the Actor. Additionally, if you wish to create any references and then access them in the Actor Core of child overrides then this is the only place to do it, I see it as a "Constructor" of sorts.

However, there is no "Destructor" where these references are guaranteed to be cleaned up. It seems there should be a cleanup VI after <Actor Core> but before <Send Last Ack>?

How are other people using <Pre Launch Init> and how are they dealing with cleanup?

Many thanks,

Steve.

[LVB]

Stop Core is your cleanup and it will be called if pre-launch does not return an error.

[St3ve]

As you say, that is conditional on <Actor Core> running which is not guaranteed. In the case of an error during launch <Actor Core> will not run, due to the error case structure, and then <Stop Core> will not be called. It seems that a small improvement might be if <Stop> where moved from <Actor Core> to <Actor> such that it is guaranteed to run and perform any cleanup required in ALL cases.

I am not suggesting that this is a major problem with the framework, just the opposite! It seems a minor flaw which could easily be fixed in a future release. Is the soucre available on Bitbucket or Github so that I could make a pull request?

Regards,

Steve.

---%<----------EDIT-----------%<---

LVB,

I see you had already made a similar point in an earlier conversation: https://decibel.ni.com/content/message/35260#35260 and in responce <Actor Core> was modified so that <Stop> was outside the error structure. However, this does not seem to fix the problem due to the outer error case structure in <Actor>. e.g, if an error occurs in <Pre Launch Init> then <Actor Core> is never called and consequently neither is <Stop> regardless of whether it is inside or outside of the error case structure in <Actor Core>. As an aside, the error structure in <Actor Core> (second image) looks to be unnecessary due to the "outer error case structure" I have labelled in the first image.

I am suggesting that <Stop> should be moved to where I have indicated, it could be called conditionally in the same way as <Pre Launch Init> is i.e., such that it is ALWAYS called if <Pre Launch Init> has been called but not otherwise.

[David_Staab]

For now, don't initialize references in Pre Launch Init. Just check for startup conditions there, and init the references in your Actor Core.vi override before Call Parent Method.

[St3ve]

Hi David,

I can see that is a solution but taking that approach does mean that children of that actor who wish to futher extend the functionality (by overriding <Actor Core> again and putting more helper loops down) will not have those refernces and data available.

This is not a showstopper by any means I was just trying to highlight a minor flaw so that it might be fixed in future versions. <Pre Launch Init> seems to be intended as a Constructor and <Stop> is the mirror Destructor. Due to the various error case structures it just happens that <Stop> will not always be able to cleanup after <Pre Launch Init>. It also seems, from the thread that I linked, that a previous "fix" had been applied that does not quite address the problem.

Regards,

Steve.

[David_Staab]

I agree that it's a probable design flaw. I just don't think anything's going to be done about it becase of the dramatic change you recommend to fix it. So I recommended taking the approach that I do, just to get you going again.

[DerekTrepanier]

Won't these references get cleaned up automatically when the actor.vi code stops executing?

Admittedly, I don't like the "don't worry about it, it'll just happend" approach, but I'm pretty sure it'll cover your back here.

[St3ve]

I wouldn't say it is a dramatic change: there is no alteration to any interface, no additional VIs or any loss or change to the functionality for current users. The change I suggested would merely lead to fully consistant and expected behaviour.

At the moment I have just patched my installation of the Actor Framework. As I was considering it a bug I wanted to bring it to the attention of others... It would be good if there was a Bitbucket or Github site hosting a more regularly released version.

[AristosQueue (NI)]

Stop Core has as its predicate that Actor Core started running. It runs unconditionally if Actor Core starts. Moving Stop Core.vi would not be a good idea -- it would break that assumption. That assumption means that Stop Core may currently assume that some static refnum fields are populated within the actor because those get filled in during Actor Core. Moving it would break that assumption.

The way Pre-Launch Init.vi was designed, you should acquire all the references you need in there as a chokepoint when no other actor can be loading -- it guarantees atomnicity in a way no other method does. If you encounter an error in there, you shouldn't leave with a half-baked set of references -- release what you acquired, similar to what I do in this VI:

ActorFramework\Message Priority Queue\Obtain Priority Queue.vi

[St3ve]

>> Stop Core has as its predicate that Actor Core started running. It runs unconditionally if Actor Core starts.

I see, that makes sense and I would agree that moving <Stop> would then be a poor decision.

>> similar to what I do in this VI: ActorFramework\Message Priority Queue\Obtain Priority Queue.vi

That is actually what I am currently doing. I just felt it was a bit of a work around and that there was a lack of symmetry that could be fixed with a <Post Run Cleanup> VI where I indicated.

I understand that LabVIEW does not actually have Constructors and Destructors but without the ability to drop an object control or constant and set the values it is often necessary to have VIs that are analogues. Additionaly, as a LabVIEW programmer I am familiar with APIs that follow a  Configure, Operate, Cleanup (which runs on error) paradigm. As such, I still think that an addition of a cleanup VI as a mirror of <Pre Launch Init> would be of benefit.

On an separate note... many thanks on providing an excellent framework!