Run Method should not run in the user interface thread

[Mads]

The Run Method is pretty much the only option we have in LabVIEW to scale an application dynamically by instantiating new VIs - but there is one big catch - for some reason it requires the unser interface to be idle(!).

Related methods like setting control values e.g. do not have this requirement so they do not pose a problem - but the main method for dynamic instantiation does - and can be blocked by something as simple as a user that opens the calendar view of a date and time control (which of course never should do this either, but that's another issue/idea).

Personally I use the run method to create new trend windows (you never know how many trends a user wants to see at the same time), create session handlers for remote clients etc. The times it is used to actually create user interfaces it is not a big problem that the run method is in the user interface thread, but for session handlers and other things that needs to be created in the background based on requests from the outside? A HUGE issue.

[TomOrr0W]

The newer methods of doing asynchronous calls (using open VI Reference with a typed reference and Start Asynchronous Call) also appear to require the root loop.  However they only require it to open the VI Reference, not to make the asynchronous call.

Tested with the block diagram below in LabVIEW 2018 (open the calendar of the time stamp control within 3 seconds of starting the code):

I also tried option flags 0x80 and 0x100, as well as changing reentrance types of the vi being called.  If you move the wait to be between Open VI Reference and the Start Asynchronous Call, the code will run in parallel with the calendar being open.

On the other hand, this block diagram does a synchronous call by reference in parallel with the calendar being open:

[wiebe@CARYA]

The call by reference also blocks when the user opens a RTM menu (at least in LV13).

This is a real problem... You make an application, everything works fine, add a menu and things stop working. Or the user opens a menu, and that was never tested. Same result. If you can find this obscure bug waiting to happen, you'll need to refactor all the call by reference nodes and replace them with set control value, run method and get control value.

I don't really see why we can make this functionality the hard way with methods, and it's not possible to have the call by reference do this properly?

This limitation of call by reference basically renders the function useless. Every application that uses them, runs the risk of stopping to work properly when a menu is added anywhere. The function can't be used in libraries, as it can't be guaranteed to work in even basic applications.

[AristosQueue (NI)]

Weibe: Call By Ref only requires UI thread for remote calls. Calls within the same application instance do not.

[wiebe@CARYA]

@AQ:

You're right about the CBR. It's the Open VI Reference that is blocked by a menu activation. We had to do some serious refactoring in an application. It's a real pain, that typically goes unnoticed until the end of development.

So this simple VI loops 10 times per second, until a menu is activated. Then it stops until the menu is deactivated.

The static ref\name\open is just an example, every usage of Open VI Reference is blocked by an activated menu.

[TomOrr0W]

@wiebe

If you have a fixed number of calls to make by reference, you can use the static reference directly instead of using Open VI Reference, which avoids blocking.  However, if you need to branch the reference to multiple calls simultaneously rather than using copies of it, the calls will wait for each other instead.  Also, these would be static calls instead of dynamic calls, so I believe the loading would not be deferred.

I believe that the UI thread/root loop issue applies to the use case for Call By Reference where you don't want your entire application to load at one time (and therefore are using Open VI Reference with a path and type reference wired in rather than using a static reference and its VI Name/VI Path property).  I rarely use Call By Reference, so therefore I don't know if another use case for it exists; I usually either use asynchronous calls (also by reference) or drop subVIs directly onto block diagrams.

@AQ
The references in the screenshot above would be static references, so they wouldn't need to be closed, correct?

[drjdpowell]

Weibe, did you check that the Run method does not block?  When I looked into this a few versions ago, Run blocks on Root Loop.  The only way the avoid Root Loop blocking I know of is the method used in Messenger Library and the AF: a shared-clone pool that calls functionality by dynamic dispatch.

[wiebe@CARYA]

@drjdpowell:

It's been a while. I think we might actually refactored the Run Method to the CBR, and then found out the open method blocked. You and I will manage to overcome this, but I'm not sure how to explain and\or justify this to beginners.

This is a typical example of how simple things in LabVIEW can get sour fast.

[wiebe@CARYA]

---

@

If you have a fixed number of calls to make by reference, you can use the static reference directly instead of using Open VI Reference, which avoids blocking.  

This isn't my application, just a mockup.

The open could for instance open a clone of the static reference. Or the path could come from a file.

---

@

  However, if you need to branch the reference to multiple calls simultaneously rather than using copies of it, the calls will wait for each other instead. 

Yes, as expected. Unless the Open VI Reference opens a clone of course.

The point is that if anywhere in my entire applications a reference is opened for whatever reason, this will hang when the user opens any menu.

This is stuff even most CLAs will get headaches from, if\when they are unlucky enough to run into it.

[TomOrr0W]

While looking into drjdpowell's post, I ended up making the following (somewhat related to this discussion) post: https://forums.ni.com/t5/Actor-Framework-Discussions/Asynchronous-Calls-in-the-Actor-Framework/td-p/...

[drjdpowell]

A related past conversation:

Suggestion: open a ref to Actor.vi only on first call