Messenger library: Program stuck on shut down

[dhendrix11]

I've got a program based on messenger library that fails to shut down properly.  Hoping someone can advise if I'm doing something wrong or if it's potentially a library issue.  Attached is some code that reproduces the issue. There's a #info bookmark in there that will show you where you can change code to make the problem behavior go away. But a brief description:

• Main.vi loads ActorA. ActorA dynamically loads a child of Colors.lvclass (Red.lvclass) through 'Get LV Class Default Value'.
• ActorA starts up ActorB (a reentrant actor) and passes Red.lvclass to ActorB as part of the startup parameters and inserts ActorB's front panel into a subpanel on ActorA's FP.
• ActorB starts up ActorC and inserts ActorC's front panel into a subpanel on ActorB's FP.
• Upon closing Main.vi, ActorC appears to terminate correctly as it's FP disappears from ActorB. 
• ActorB remains in the subpanel of ActorA and ActorA changes it's run state to 'SubVI Waiting to Run', where ActorA is not editable, nor is the FP closable. In order to shut things down, the containing project must be closed. If Main.vi is loaded directly (rather than vi a project), the only way to close ActorA is to task manager shutdown Labview. Most of the time, closing the project resets everything. However, sometimes, Labview appears to close (the Labview taskbar item in windows goes away), but there's still a Labview background process running that needs to be killed in task manager. You can notice this because labview will fail to re-open in the instances it looks closed but the background process is still there.

Observations:

• If ActorA is run directly rather than being launched from Main.vi, everything works fine.
• If ActorC is loaded via 'Get LV Class Default Value before loading Red.lvclass, everything works fine.  
• The reentrancy of ActorB seems unimportant. I've changed it to non-reentrant and get the same problem.
• If I simply never run ActorC from ActorB, I also don't see the problem. Obviously that's not functionally the same, but ActorC isn't consuming the Colors/Red.lvclass data, so there really shouldn't be any relational behavior. 
• I've also tried reverse sequentially shutting the Actors down through direct messages (C then B then A) rather then Auto shutting down when the parent actor dies, but the behavior is the same.

I've tried implementing the second bulleted item in my actual program with limited success.  For some 3rd level actors (in place of ActorC), loading them dynamically on the front end will solve the problem.....most of the time.... But occasionally it still does fail, which makes me suspect some race condition.  

I'm doing this on Windows11, LV2024Q3 32bit

[drjdpowell]

Sorry, I didn't see this till recently.

It smells a lot like a variation on Issue#9: drjdpowell / messenger-library — Bitbucket

But it can't be that issue exactly as the setup is different, but the leaving classes locked thing is very similar, so it might be a related bug.

[dhendrix11]

Sorting through the trails of threads on the topic is going to take some more effort.  Removing the strict type from 'Dynamic Launch Shell ActorNR.vi' reference within 'Get Dynamic Launch Shell Reference ActorNR.vi' does make the problem go away,  I just don't quite understand the implications of doing so and/or the exact reasoning behind why the ActorNR version of Get Shell Reference retains the strict type.

For fun, I also tried setting 'Dynamic Launch Shell.vi' reference to strict in 'Get Dynamic Launch Shell.vi'.  When doing that, All three of ActorA, ActorB, and ActorC remain locked after shutting down Main.vi, instead of just ActorA and ActorB.  

[dhendrix11]

Coming back to Issue#9 on your bitbucket, let's see if I'm understanding this right....

At the time your issue was logged, there was a bug doing the following:

• Create a messenger library ActorNR.  Create any subactor (the issue doesn't specify whether this second actor should be re-entrant or non-reentrant.)
• Run the first ActorNR by itself, i.e. 'Top Level' according to the framework.
• Launch the subactor from within the first ActorNR.  If the VI ref to 'Dynamic Launch Shell.vi' was non-strict, then the subactor wouldn't launch. 
• As a fix to this issue, change the 'Dynamic Launch Shell.vi' ref to strict, but this created a new issue as described in first comment in your bitbucket link, which was then logged as a bug to NI via CAR 678300.
• Later, you added a workaround by creating a separate 'Dynamic Launch Shell ActorNR.vi' which is vi ref'd as a strict VI ref, while 'Dynamic Launch Shell.vi' is ref'd as non-strict according to https://web.archive.org/web/20190419053339/https://labviewcoder.com/2016/07/06/quick-tip-asynchronou...

So my questions/comments are:

• What was the outcome of CAR 678300?
• It seems like the original issue described in Issue#9 is no longer present in some version of LabVIEW...?  In LV2024, if I run and ActorNR started by itself, I can successfully launch a re-entrant subactor non-strict reference 'Dynamic Launch Shell.vi' or I can launch a NR subactor via the default code, which is a strict ref'd 'Dynamic Launch Shell ActorNR.vi' OR I can change to a non-strict ref'd 'Dynamic Launch Shell ActorNR.vi' and everything still works.  So is this a behavior that was fixed at some point, or am I mis-understanding or doing something wrong?
• If my understanding of bullet #2 is correct, why is 'Dynamic Launch Shell ActorNR.vi' still strict ref'd in 'Get Dynamic Launch Shell Reference ActorNR.vi'?

I'm working this as support ticket with NI, and they asked whether I could create the issue outside of messenger library.  Having not used the native LV Actor Framework before, I dug into that a bit and noticed there was no concept of an non-reentrant actor, and all subactors are launched in essentially the same manner as messenger library re-entrant actors, and the dynamic launch shell uses the non-strict vi ref.  

I created NR versions of everything for the native Actor Framework, similar to messenger library, and I was quickly able to reproduce the issue if using the strict type'd vi ref in my 'Launch Actor CoreNR.vi', which leads me back to the same question, why is the NR Dynamic launch shell using a strict ref?

Seems like a LV bug as the actual lockup only occurs if I load the child of a totally unrelated class before I launch my subactor, and the Dynamic launch shell ref is strictly typed.

[drjdpowell]

I don't think there is any real problem with you changing that reference to non-strict, and I may do so in the next release of Messenger Library. The only issues this causes are:

1) If you run an non-reentrant actor from the Run Arrow (rather than launching it) it will not be able to launch another non-reentrant actor (will get Error 402824).  Originally, one could not launch any actor, but the changes I made in the past, that separates Actor.vi and ActorNR.vi calling, mean that this doesn't happen with reentrant actors.

2) if a non-renetrant actor is broken, its callers will NOT by broken.  Instead you will get a run-time error when trying to launch it (which is harder to debug).

These are dubugging annoyances rather than major problems.  I think I left the strict reference in for non-reentrant actors just becasue I could, and quite a lot of my day-to-day development involves non-reentrant actors.  Having the calling actors break if their callees are broken, rather than throw runtime errors, saves me a lot of time.  But the problem you are having is more serious.

[drjdpowell]

Can you do me a favour?   Leave the NR code using a strict ref and instead change the reentrant version to also use a strict reference (in "Get Dynamic Launch Shell Reference.vi").  Does that fix your problem as well?  

[David_Hendrix]

See my second post in the thread.  Changing the reentrant to strict made all 3 actors lock instead of just A and B.

[David_Hendrix]

I'll have to investigate this a little more.  I wasn't necessarily seeing the NR failing to launch another NR issue originally, but we just made a code change moving one of the actor launches into a subVI and it created a new issue which is or closely resembles this.  My short term fix was simply to remove my top-level VI's class inheritance so it's not a messenger library object.  I'll post any more relevant details when I'm back in front of that code.