LabVIEW
Call Library Node: internal LV data operations
Not really! The LabVIEW data is dynamic.
There is absolutely no guarantee that the handle that you pass into the Call Library Node will stay the same after the Call Library Node call returned control to the diagram. LabVIEW reserves the right to (re)allocate, deallocate, resize and change data handles at any time and only gives guarantees that handles that you pass into a Call Library Node will never change as long as that Call Library Node doesn't return. Expecting anything else is at best a Russian roulette play that will at some point cause you to shoot your feet, and at worst cause real causalities, depending where your application is used.
LabVIEW data is ALWAYS dataflow controlled. What you attempt to do is not dataflow and therefore will not work.
When you want to have a memory pool that is controlled by you you have to allocate it, manage it and deallocate it.
When you want to use a LabVIEW data handle you can ONLY manipulate it during the call to your Call Library Node function. After your function returned, LabVIEW takes over control of that handle again and reserves every right under the sun to resize, relocate and/or deallocate this handle at its own will. So storing a pointer to that handle and hoping to read and/or write it later on after your function has returned control to the LabVIEW diagram is simply creating a crash to happen sooner or later.
As another contributor on this forum keeps saying: Think dataflow!
Forgot those text programming techniques of storing some (static) global somewhere that is accessed all over the place by various routines, possibly even in different code modules, and creates all kinds of trouble requiring extra access control through mutexes or other such things once you happen to start up at least one other thread that also happens to call those functions. LabVIEW has 5 execution systems with each containing by default 8 threads that all can be active in parallel and a DLL trying to tweak its own memory management paradigma in there is simply creating a chaos. You either follow LabVIEW data management rules or create your own memory space that you then have to manage yourself from start to end. Mix and match between the two is not advisable and creates all kind of trouble that make your VIs very difficult to use and totally counter-intuitive to what a normal LabVIEW programmer is used to. Even if you think you know exactly how you have to call your library and wire the wires in the diagram to make sure the handles stay artificially in place until your DLL is truely done with them. I can almost guarantee you that even you will somehow create trouble if you revisit the same application a half year from now to make this last simple feature addition that makes it complete.
A seemingly small change will suddenly cause the DLL to try to access this pointer after your LabVIEW diagram has already ceased to run this wire through the whole state machine or whatever you have, to make sure the handle stays alive, and LabVIEW consequently deallocated or resized it (and resizing can mean that a handle is relocated to a different memory space). In addition even if the handle is still valid you would still have to add extra protection to it to make sure that you are not modifying it asynchronously in the DLL while your LabVIEW diagram somewhere tries to access it, to prevent inconsistent data, or in the case of a resizing on either side even an invalid handle.
