LabVIEW
Preventing DVR Cleanup, DVR of DVRs
I think he understands the issue, he's just looking for a way around it.
Unfortunately I don't think there's a simple workaround here. See this thread for some previous discussion:
https://forums.ni.com/t5/LabVIEW/When-are-DVRs-automatically-deleted/td-p/3240205
Is the number of DVR's known in advance, or do the dynamically called children make an arbitrary number of them? If it's known ahead of time, just have the caller create the DVR(s) for the child when it gets launched. If it's not known ahead of time I don't think you can have your (dynamically launched) child spawn the DVR, and you'll need to implement some sort of messaging architecture to communicate between the processes. In general, having a messaging system between callers and dynamically launched children is a good architecture to use (see the Actor Framework or any of the QMH design patterns).
What kind of data are you communicating over these DVR's? Maybe there's a better way to do it that doesn't involve creating multiple DVR's at runtime.
Sounds like you could use a functional global...
I'd look for ways to completely refactor the DVRs (and functional globals) out. But that would require full understanding of the entire problem.
Search LabVIEW like a graph!
@_carl wrote:
I would have expected a simple functional global to work as well, but it didn't -- it seemed like the life of the DVR was determined by the VI (or thread) calling the functional global. (The functional global did successfully create and store the DVR -- it was just that the reference would become invalid once I closed VI2 from the original description (even though both VI1 and VI2 used the functional global).
A LabVIEW reference (almost any type) is closed once the top level data space of the creating VI stops.
This is well defined behavior.
@_carl wrote:I ended up just spinning off a temporary parallel queue-based process that would do nothing other than create DVRs on request and keep them in memory until I was done with the DVRs. Unlike a functional global, this VI would remain running the entire time, which seemed to be key.
Ah, the broker pattern.
That works, but the hard part is to make it stop when it's not needed anymore.
You can keep it running, but at some point you'll get an annoying popup that closing LabVIEW will close some running VIs.
@Guillermo.O wrote:
Hi Wiebe@CARYA,
I just faced a similar issue, and something that helped me (other than reading your posts and your feature request, which I already kudoed) was before closing the process that created many of your DVRs, you would need to regenerate those DVRs from the process that will remain executing. This will act as passing the ownership over that data from one top VI to another. And it is an operation fairly simple, where you would need just to access its content, and then create a new DVR and replace it in your array of DVRs, all of this from the process that you are planning on kepping alive.
Let me know if this makes sense to you.
Yes, that's a way to deal with references. Creating them in something that keeps running is required. It's often trivial, but if it isn't it can be puzzling. You can make a broker for that (a dynamically running VI, that in turn does need to close at some point).
Beside the life time of references, by using anything by reference (incl. locals, (functional) globals, property\invoke nodes), you introduce a risk of race conditions.
Pure by wire programming cannot have race conditions. Of course you need some 'side effects' (done with terminals, locals, prop\invoke nodes, CFLN, etc.), but the fewer you need, the easier they can be managed (to avoid race conditions).
