Leaderboard

Thank you for this it looks like some good tidbits are in there. I would say it is slathered in marketing BS. Sadly marketing has stuck its fat ugly hand into LabVIEW very deeply and we'll need some sort of proctologist to remove it.

I'm hoping he'll hijack all those and replace them with ones we can send arguments to 10 years ago I complained about this to NI We'll need to talk about how we configure such a hack (per project, per VI, per node, per IDE, any or all of the above? )

This has other positive implications for developers that interface to external code. One issue I (we?) have is that we cannot pass opaque pointers to the "abort", "reserved" and "unreserved callbacks" in CLFNs which are direct hooks to the LabVIEW IDE. Many 3rd party API libraries have an Init and Deinit procedure which is global. You only want to de-init if An init succeeded and allocated resources(no error, say) No residual inits are floating around from the last run. However, the callbacks for the CLFN are on each node so you only know that you can cater for 1&2 if the last node is executed and other nodes didn't error. Aborting in the IDE LabVIEW stops it dead before the last node and therefore you leak the callback. Any other strategy results in a crash of LabVIEW because you don't know whether the callback actually exists. If we had an abort hook (and a reserve and unreserve) that could take arguments then we can easily cater for this type of API. As an example. In order for the the OpenSSL library to be thread safe you must attach a callback to the library. This is a global callback, across all instances and invocations of the library and can only exist once as it is basically a mutex function. So when the library is initialised, a thread callback is created and passed to the API . You are supposed to then free the pointer and "de-init" the callback when you shut down but - and this is a "but" with a capital "CRASH" - only if you created the callback rather than another application.....bummer! Regardless of that GOTCHA; when you abort the IDE, however, you cannot execute your shutdown function which is in the close or De Init VI. Similarly, There is no way to track the callback instance from the LabVIEW dev environment since the pointer allocation exists outside of LabVIEW so you don;lt know how many de-inits to call to clean up. So when you press abort, you leak that callback until LabVIEW exits and the OS cleans it up for you. Ideally, we would use the abort, reserved and unreserved callback function of the CFLN to clean up. (Note that this is not a problem in an application as a Close or De-Init can always be called and is no worse than forgetting to close a queue refnum) Now. NI will argue that you can create these functions in you DLL and call them so it's not a problem. Except that, of course that would only work if you run all nodes in the root loop which defeats the whole point of multi-threaded callback -DOH! (as well as a huge performance hit).Additionally and probably even worse for me is that I use unmolested (or I should say "untampered with" so that hashes can be checked) 3rd party code so that users can update binaries without my intervention and, of course I don't run the risk of introducing nasty, hard to trace bugs into an already extensively tested API I'm not intimate with. So your abort could also enable a global cleanup of a 3rd party API when in the IDE. We could detect the run-time engine or IDE and snatch whatever arguments the clean-up requires then, using your abort hook, pass that directly to the APIs clean up function.

If you follow and read this Blog. You will see NI discussing all the areas they are investing in for the future of LabVIEW. Interspersed with marketing BS. But the info is there. https://decibel.ni.com/content/blogs/labview-news-english/