NI Home > Community > NI Discussion Forums

LabVIEW Idea Exchange

Showing results for 
Search instead for 
Do you mean 
Announcements
We've turned on a search before post feature in the LabVIEW Idea Exchange. This new feature will help cut down on the number of duplicate ideas in this space!

The NI Idea Exchange is a product feedback forum where NI R&D and users work together to submit ideas, collaborate on their development, and vote for the ones they like best. View all of the NI Idea Exchanges to post an idea or add your opinion on an existing one today!
SteenSchmidt

Make it possible to dispatch VIs dynamically when the UI thread is blocked (or introduce multiple UI threads)

Status: Duplicate
by Active Participant SteenSchmidt on ‎05-30-2011 04:09 PM

Many LabVIEW functions use the UI thread, like DataSocket (due to ActiveX events IIRC), everything VI Server etc., and since there is only one UI thread (per LV instance, no matter the number of logical processors, right? Also on Real-Time?) these functions are blocked when the UI thread is occupied by something else.

 

What I find particularly troubling is the fact that you can't dispatch VIs dynamically when the UI thread is blocked - for instance if a dialog is open or a user is selecting something in the menu. The latter can be an application blocker, if you are dispatching 20 VIs to populate your UI for example, and the user clicks the menu bar (without selecting something), your app might freeze since you won't be able to dispatch anymore VIs until the user lets go of the menu bar. There are many much simpler scenarios that you'll hit more often (a DataSocket read with a long timeout may block your dynamic VI from loading?).

 

Upping the count of UI threads from one to several would be great, but probably out of the question due to the implications to the LabVIEW core.

 

Instead, could we at least get the 'Open VI Reference' function and the 'Run VI' VI Server method freed from the UI thread? That would enable dynamic dispatching while the UI thread is blocked. Other VI Server calls aren't that important to get out of the UI thread, since there are other (and better) ways to transfer data to your dynamic VI for instance, than with VI Server. One curious thing is that it's possible to open all the 'One Button Dialogs' you want in parallel for instance - I'd think they'd run in the UI thread, and hence the first one'd block the rest?

 

A (somewhat contrived) example that fails due to this limitation:

 

DynDispatch.png

The blue statement is true even when DynVI doesn't touch the UI thread, and even when no VI in the hierarchy runs in the UI thread etc. It's simply the 'Open VI Reference' primitive and the invoke node that gets blocked, due to the one button dialog being open.

 

Cheers,

Steen

Comments
by Active Participant Mads on ‎05-31-2011 12:46 AM
by Active Participant SteenSchmidt on ‎05-31-2011 06:39 AM

Thanks, this is a duplicate then, and I understand the issues involved from the earlier post(s) you link to.

 

Cheers,

Steen

Latest LabVIEW Idea Exchange Blog Posts
About LabVIEW Idea Exchange

Have a LabVIEW Idea?

  1. Browse by label or search in the LabVIEW Idea Exchange to see if your idea has previously been submitted. If your idea exists be sure to vote for the idea by giving it kudos to indicate your approval!
  2. If your idea has not been submitted click Post New Idea to submit a product idea to the LabVIEW Idea Exchange. Be sure to submit a separate post for each idea.
  3. Watch as the community gives your idea kudos and adds their input.
  4. As NI R&D considers the idea, they will change the idea status.
  5. Give kudos to other ideas that you would like to see in a future version of LabVIEW!
Idea Statuses
Top Kudoed Authors
User Kudos Count
82
55
47
37
34