Actor Framework Discussions

cancel
Showing results for 
Search instead for 
Did you mean: 

Handling Last Ack from Pre-Launch Init

Solved!
Go to solution

My current understanding with handling Last Acks is that you should compare the enqueuer returned by 'Last Ack:Read Caller-To-Actor Enqueuer.vi' with your list of nested actor enqueuers, in order to identify the actor which quit.

 

This works pretty well for me when the actor was running. However, if the Pre-Launch Init for an actor fails, the Launch Actor vi can't dequeue the message enqueuer because the 'queue of queues' has been released by 'Actor.vi'. This means that the Message Enqueuer returned by Launch Nested Actor is an invalid queue. Consequently, I can't compare my enqueuer returned by LNA with the enqueuer returned by LA:Read Caller-To-Actor Enqueuer (right?).

 

I can use something like 'Clear Errors' following the LNA to prevent shutdown of the calling actor, but I can't find a way to prevent the error returned as part of the Last Ack from shutting down the calling actor without filtering against the error in every case - i.e. for all actors, rather than just some specific (set of) called actor(s).

 

Is there some obvious work around here?

Reading some of the other threads I could find here seems to suggest I might be best served by, for example, throwing a different custom error in Pre-Launch Init which I then always filter, and ignoring/clearing within Pre-Launch the actual error (perhaps with logging, if I'd gotten that far...)


GCentral
Message 1 of 5
(4,103 Views)

And looking closer, presumably the sensible answer is instead of 'Read Caller-To-Actor Enqueuer', use 'Read Actor' followed by 'To More Specific Class', through an array of all the classes I want some specific handling for?


GCentral
0 Kudos
Message 2 of 5
(4,080 Views)
Solution
Accepted by topic author cbutcher

This is a bug; thanks for finding it.  The good news is that it is a bug in the AF G code itself, and easy to fix.

 

I just filed a CAR to get this resolved.  The CAR is high priority, and will hopefully be addressed soon.

 

You have two options going forward:

 

1)  You can work around the problem by filtering your Last Ack messages.  You are correct in that you do not have the nested actor's enqueuer to use as the filter, so you will have to filter out Last Acks where you do not recognize the returned enqueuer.  This is suboptimal, because you have to make sure you capture the enqueuer of every actor you launch, and you may not want to do that.  But it might get you by.

 

2)  You can fix your local copy of AF.  The solution is pretty trivial, and I have attached a screen shot showing what you need to do.  The downsides are the usual issues that arise when you modify code in vi.lib, namely, you must do it on every machine that will run your application (and risk missing a few), and you will lose the fix on a given machine if you reinstall/repair LabVIEW.

 

2) is the most technically correct solution, but 1) may be the more correct solution for your organization.

 

I hope this helps.

 

(Edited to highlight the change in the image)

0 Kudos
Message 3 of 5
(4,068 Views)

Was this fixed in a release yet?  If not, could you share the CAR number so we can lookout for when it's released?

 

Thanks!

0 Kudos
Message 4 of 5
(3,046 Views)

The CAR number is 624304, and it was fixed in LV 2017.

 

It's included in the LabVIEW 2017 Readme in the bugfix section: http://www.ni.com/pdf/manuals/374715g.html

Craig H. | CLA CTA CLED | Applications Engineer | NI Employee 2012-2023
0 Kudos
Message 5 of 5
(3,044 Views)