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:
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.