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.

[AristosQueue (NI)]

> Related methods like setting control values e.g.

> do not have this requirement so they do not pose a problem

All control, VI and application methods and properties require the UI thread. If the UI thread is tied up with the calendar display (and, as I posted on your other idea, I have no idea why this would be), then all properties/methods that need the UI thread will be impacted. You seem to think that some methods aren't affected. I'm not sure what you are seeing, but either the UI thread is locked and so none of the properties/methods can proceed, or the UI thread is not locked and something else is interfering with the Run method.

The properties and methods must be in the UI thread because of all the resources in use simultaneously, and because the UI states are variously updated by these functions. That's unlikely to be changeable.

[Mads]

You are correct. The reason for the statement was due to the following difference in the help window:

If you go into the detailed help of the Set method it says:

"

Must wait until user interface is idle

No

"

If you check the same for the run method you get:

Must wait until user interface is idle

Yes

So the help info seems to think there is some difference...

This all got my attention when I noticed that if you open the calendar of a date/time control then all calls to the run method are halted (which in my case is rather critical for a lot of applications). At the time I only tested and verified that the run method got blocked, and trusted the help window that the set method would not be affected. As it turns out the calendar will block them both.

The problem with this is that if you need to instatiate VIs in the background to enable parallell processing of different things (e.g. a session handler for each TCP/IP client connection) - then the best option you have is to use the run method with the wait set to false...This now has the ugly behaviour that it may be interrupted by the user interface, and in the case of the calendar control and some dialogs - it will halt alltogether.

[AristosQueue (NI)]

OH. The terminology used in the code and the terminology that eventually ends up in the help for users isn't always the same. Now I know what you're complaining about. You want to know why the Run method "Requires Root Loop" (that's the term from the code side of things). This is pretty straightforward to explain: The UI thread can do "cooperative multitasking", to allow many methods/properties to appear to run in parallel even though they all require the UI thread by giving each of them a little bit of time. But some operations, particularly those that affect multiple VIs simultaneously, cannot proceed together. Trying to process a Run command at the same time as scripting a Drop SubVI node would be particularly messy, just to pick one example. There are many operations that cannot do the cooperative multitasking because they affect so much system state, and Run is one of those methods. That's definitely not something that can change.

[Mads]

Ok, but how do you propose we handle situations like the one I'm describing - where you need to dynamically instantiate a VI that can handle e.g. incoming client connections (because handling them in sequence would not work)? Do we always have to live with the risk that user interface events might slow or block the creation of such handlers, that seems to be very limiting - does it not?

I could e.g. instantiate a pool of idle VIs at the start of the application, and then use non-blocked ways to initialize and change their state whenever I need them...but that seems very inelegant.

[AristosQueue (NI)]

> Ok, but how do you propose we handle situations like the one I'm describing

I don't have a proposal for how to solve it, other than the inelegant one you suggest. I hate to rain on an idea like this without suggesting some ray of hope, but I can't think of a way to make this work out. Maybe someone else will chime in with a suggestion.

[JackDunaway]

>> Ok, but how do you propose we handle situations like the one I'm describing - where you need to dynamically instantiate a VI that can handle e.g. incoming client connections (because handling them in sequence would not work)?

Perhaps, run the remote client server in a separate application instance from the GUI and communicate via TCP/IP? Just throwing out ideas.

[AristosQueue (NI)]

All app instances in one copy of LabVIEW have a single UI thread. You'd need to be running two different copies of LabVIEW.exe for that approach to work.

[Mads]

Sure, and we do have applications where we have dropped the local GUI (run it as a service...hence another idea of mine; allow us to build proper services), and that will reduce the risk of problems...but that's not always a wanted solution, and it certainly seems unnecessary to actually *have* to do it that way.

Creating and running a copy of a VI should not happen in the user interface thread in the first place. It's OK whenever a VI actually is used as a "Virtual Instrument" or a user interface, but VIs are more often used as functions. They should be possible to instantiate very quickly and safely. It seems like a fundamental flaw to allow the user interface to interfer with something like that.

[JackDunaway]

See comment and video here. +1 on this Idea.

[Marc Blumentritt]

See this idea from Jim Kring.

This is a very important and much needed feature. E.g. I have VIs, which are loaded via VI reference, than sleep in the background for a configured time, than insert an element in queue, notifier, what ever. I use these VIs for asynchronus insertion of states (e.g. do this or this appropriatly every 5 seconds).

Therefore a big +1, but vote on the other idea(s) for a better method to fork, too!