How to do Last ACK in 'Simple Actor Example' in LV2014?

[DMurrayIRL]

I'm trying to figure out how the Last Ack code works in the Simple Actor Example project found in this hands-on (also shown below), but I can't see how it should work with LV2014, because I don't use the Obtain Message Queue VI in any of my code (I've never used AF before LV2014). So, for example, its not clear where the input for the Read Dequeuer VI comes from in LV2014. Possibly I'm missing something obvious, but can someone please explain how this code should be changed in LV2014?

[justACS]

This code runs in 2014, thought it uses Launch Actor in its original form.  That form is theoretically deprecated.  (I say "theoretically" because I think there are still corner cases, like this one, where it is still useful, and so it will remain available, if somewhat hidden.)

This is an example of a test harness - non-AF code used to test your AF code.  If you don't want to use the original form of Launch Actor, you would roll most of this code into another actor.  This new actor would have a UI that had buttons to launch new actors, etc.  The top loop would become a helper loop of that new actor, servicing user events.  The cotents of the case structure inside the bottom loop would become the contents of an override of Handle Last Ack Core.vi.  The rest of the contents of the while loop would be deprecated.

The test harness actor would be launched by a little launcher VI that just called Launch Root Actor.

All of the message queue managment you see in this VI is work you do when you have to handle message queues in non-actor VIs.  A Message Queue is a wrapper for a set of regular LabVIEW queues.  You can only do two things with a Message Queue:  obbtain it, release it, get an Enqueuer object or get a Dequeuer object.  The only thing you can do with an Enqueuer is put messages on the Message Queue, and the only thing you can do with a Dequeuer is take messages off of the Message Queue.  This is for your safety.  In normal Actor Framework code, you never see a Message Queue (or a Dequeuer, for that matter), because you don't need to.  You only need Enqueuers.  We've exposed the API to you so you can use them in corner cases like this test harness.  They're even less important now that we have Launch Root Actor.

[dsavir]

Hi,

If you're calling your actor from another actor, handle last ack would be handled in handle last ack core.vi (override it). Each acotr already has an enqueuer and dequeuer built in, so you don't have to obtain it using hte obtain queue VI. The dequeuer is handled for you and sends all last acks to handle last ack core,a nd the enqueuer can be obtained using read self enqueuer.vi on the calling actor.

If you're calling your actor form a non-actor, then use the code above exactly as written. Except for a large X appearing on the "launch actor.vi" icon, it should work fine.

Good luck!

Danielle

[DMurrayIRL]

Thanks for the replies guys, that's helpful, but I'm still strugging with how to implement Last Ack in general in normal actor code. There are no clear and obvious examples of how to do this, especially in LV2014.

So, say I have a Caller Actor, which launches a Nested Actor. In the private data cluster of Nested Actor I put a string called "Last Ack String". In Caller Actor I put a simple stop button mechanism to close down Nested Actor (with Caller Actor still running), and when that happens I want (a) Nested Actor to update "Last Ack String" with "Nested Actor Closed Down", and (b) Caller Actor should be able to read this string. What are the steps I need to do to achieve this?

[minor rant] As an aside, my biggest gripe with AF is that some things which are really simple on paper (like the above) appear really difficult to implement. And it's not because they actually are difficult to implement, it's more that the fundamentals aren't explained properly, with simple example code. I had the same issue with zero-coupled messages, where it took me about 20 hours to work out what was going on. I really like AF and can see the power in it, but it shouldn't be so difficult to learn! [/minor rant].

[MattP · Accepted solution]

Handle last ack will transfer a copy of the actor in its final state to its caller.  To extract data from this actor wire and put it somewhere useful in your caller, the callee actor needs to expose non-private methods that are called from the caller's Handle Last Ack.

A key conceptual point here is that if Actor A calls Actor B, and you want Actor A to do something with the final state of Actor B, you need to override Actor A's Handle Last Ack method with an implementation that calls an exposed method of Actor B.  Overriding Actor B's Handle Last Ack won't get you what you need - this method is used by the caller when it is told a caller has shut down, so overriding the callee method doesn't help.

I do some of this in the coffee shop example (to remove the newly shutdown caller from the UI list of active Actors).  Link to the code here: https://decibel.ni.com/content/thread/12560

Note that this code is a bit out of date (wasn't updated for Launch Nested Actor), I've got a newer example that is fully updated that should be released soon.

[DMurrayIRL]

MattP- Thank you very much for pointing me to your code. A quick look through it, and literally 5 minutes of coding in one of my own actor test programs, and I have Last Ack nailed. I was approaching it from the wrong direction - I assumed that Handle Last Ack had to be overriden in the nested actor. Anyway, I've given you the Correct Answer, even though technically it wasn't the question I originally asked!

[MattP]

Glad I can help!  Took me a while to figure that one out as well.

[justACS]

DMurrayIRL wrote:

[minor rant] As an aside, my biggest gripe with AF is that some things which are really simple on paper (like the above) appear really difficult to implement. And it's not because they actually are difficult to implement, it's more that the fundamentals aren't explained properly, with simple example code. I had the same issue with zero-coupled messages, where it took me about 20 hours to work out what was going on. I really like AF and can see the power in it, but it shouldn't be so difficult to learn! [/minor rant].

I'm working on course material to address these kinds of training gaps.  The exact distribution method is a bit up in the air, though, as there doesn't seem to be enough demand (yet) to make it a regular CustEd course.

PM me if you are interested.