LabWindows/CVI
DLL created in LabVIEW hangs when used with CVI
Most likely this has to do with threading. LabVIEW front panel updates execute in a special thread inside the LabVIEW runtime that hooks into the Windows message queue. For modal panels this most likely is configured to run the whole VI in that thread. Now your LabWindows/CVI program is also a Windows application interacting with this same message queue. While your C code can run in any thread, all the CVI UI updating and some other processing happens in this same message loop that interfaces to the Windows message queue. (And unless you do explicit multi-threading, your entire CVI program is in fact single threaded and runs in this main thread).
When CVI calls the LabVIEW function there happens some locking that interacts with this message loop. Since LabVIEW locks this too you seem to get a classical mutual exclusion. The LabVIEW function can’t return before CVI has given back that lock and CVI won’t be able to give it back before the LabVIEW function returns. => perfect deadlock!
There is possibly a workaround but I haven’t done anything significant in CVI in at least 15 years and definitely not on such level. It would involve setting up a separate thread context in CVI and execute every such LabVIEW function in this special thread contaxt. The thread context will still be blocked until the LabVIEW function returns, but it won’t be the CVI main thread that also processes other important things in CVI including UI updates and interfacing to the Windows message loop.
And this is not so much a bug as a logical limitation, albeit not a very well documented one. The alternative to not do such locking would cause frequent crashes instead, when you try to interface to external code that somehow interacts with the Windows message loop. While that locking could possibly be improved by making it more fine grained, it is in the end always a compromise. Fine grained locking also consumes more resources which slows down code execution and even more important is often a lot more difficult to manage as you need to make sure that every possible code path has always exactly one lock release for every single lock acquire call. One single mismatch can either mean a fatal indefinite lock (if a code path doesn’t release a lock it acquired) or great potential for crashes (if a code path releases the lock twice). Debugging and testing this 100% is often almost impossible.
Well try to run these functions in a seperate thread context! And if you intend to call them in parallel you will need one seperate thread context per parallel instance.
But mixing and maxing UIs from different environments is always going to be a hassle. You might have to reconsider your approach and instead of calling the LabVIEW VIs with their own UI from CVI, remanufacture the VIs fo seperate out the algorithmic meat of the VIs into your DLL and call that instead, leaving the UI part in CVI to be implemented. The DLL interface has absolutely no recommended guidelines,not to speak of hard rules, how an environment should handle its UI in order to cooperate with other UI handling in different environments. As long as everything is in different processes that doesn’t typically matter as the Windows (really the x86) process separation model keeps them fully isolated and the Windows event message handling goes through some horrible loops and hoops to make sure that works that way.
A DLL however works in-process and none of those protections are present. While the original CVI UI subsystem borrowed a lot of the LabVIEW code, they were not kept in sync after the original fork and certainly diverged very considerably in the course of time. But they certainly are not meant to easily work alongside each other in the same process as they do their own thing to map the original MacOS Classic event model on the Windows event handling, since LabVIEW started on the Mac and when porting it to Windows the developers choose to keep the higher level code as much as possible and develop compatibility layers that provided interfaces similar to the Macintosh. While the Macintosh Classic model is pretty horrible when looked at from todays computer science understanding, it was a lot more functional and capable than the Windows 3.1 model, which was mostly a UI shell stacked on top of DOS.
So yes legacy plays an important role here and the chance that things could be significantly changed without a complete rewrite of both LabVIEW and CVI from ground up is very small.
Now LabVIEW NXG is a partial rewrite of LabVIEW and already for about 10 years in development, so count your apples and bananas and calculate the chances for such a complete rewrite!
