Browsing through the DummyPrimaryProvider example in the Project Provider Examples, this Open VI Reference primitive caught my attention. Can anyone explain the significance of the 'private' coloring?
This is a very good question!!!
I think David_L has a good explaination of this. In short, it allows you to perform certain VI server operations on a VI that launches a provider created menu action. Without this "enhancement" these actions would crash LabVIEW.
I ran into this problem working on the TSVN Toolkit. It was something a previous developer had stumbled on, but had not left good enough comments for me to understand what he had done, so I had to discover it all over again for myself. The problem it solved for me was trying to revert a VI that launched the menu action which performed the revert.
It is not a common scenario, but there are probably some providers that would need this. I will let David provide the details though.
Good catch Jack. This one is a fairly complicated and interesting "private" node and I didn't even realize it was in the example code. I will do my best to summarize what it is, but keep in mind that 99.9% of developers don't really need to worry about this. As with all other private features in this forum, please don't share this outside as this functionality is not completely tested and could cause more harm than good. If you choose to use this, make sure you test it thoroughly. As good old Uncle Ben said, with great power comes great responsibility.
So here goes...
The LabVIEW execution system has a main loop that runs most of the code in the LabVIEW environment (not user VIs, but other "root' level activities such as UI Handling, editor, compiler, loader, linker, etc). This code is very often single threaded in order to protect resources within the environment that may not be thread safe. Because the project provider framework is considered "part of the LabVIEW environment' it also falls into this category and therefore shares CPU resources with the rest of the LabVIEW IDE.
Because of this architecture, it is possible for problems to arise in the case where something in the project provider code calls functions that are also using the same resources as other parts of the IDE. The IDE and the provider code can then get in a deadlock state in which they are both waiting on each other and therefore LabVIEW can hang.
The good news is that since most functions and properties and methods in LabVIEW are known to be thread safe, they are configured under the hood to "run in any loop" and therefore skip this single threaded loop. Because of this they do not cause deadlocks and hangs. However not all functions and methods and VIs are tested completely in the other loops and therefore are set to run only in the root loop to be safe. Most of the time this is not a problem but in some situations it can cause LabVIEW to deadlock.
For these situations, we can manually set VI Server nodes to also "Run in any loop" which is what was done to the Open VI Reference node you found. This can also be done on other VI server properties and methods when needed. In Eric's situation, the Revert VI method was hanging when called in the Project Provider context, and changing this flag helped resolve the hang. If there are other specific methods, properties or nodes that you find are also hanging in the Provider context, please report them here and I can investigate and see if making this change will also help in that situation.
Whew... that was fun. Let me know if I wasn't clear enough about anything.