Persistent Data Value Reference (DVR)

[EthanStern]

I have long defended NI's decision to bind the lifespan of DVRs to their creator VI but, with the addition of malleability (totally awesome) and the fix in LV 2020 that allows "New Data Value Reference" to be called directly in an inlined VI (thanks, AQ), the ephemeral auto-cleanup behavior of DVRs is now a big blocker to a reference-based strictly-typed API.

I want to open a strictly-typed and malleable reference and keep that reference open until I choose to close it, regardless of whether the opener leaves memory. Without malleability, I could delegate the DVR creation to another thread/VI and get the persistent reference back by callback but I can't have the home-baked persistence and the malleabilty.

 

Please add a persistence/auto-cleanup flag to New Data Value Reference so I that reference can persist if I want it to. (I need both the persistence and the malleability to write some really cool code.)

Here's an old request for this feature that was declined, but things have changed a lot since then: https://forums.ni.com/t5/LabVIEW-Idea-Exchange/Persistent-DVR-s/idc-p/2856348#M27799 

[drjdpowell]

>That sounds like this VI.

Where'd you find that?

[wiebe@CARYA]

>That sounds like this VI.

If it did as promised, I think this idea is almost 'already implemented'. It only works for DVRs though.

For now, the function breaks the VI even if all inputs are wired ("One or more required inputs to this function are not wired or are wired incorrectly.").

Either there's a trick or it's disabled.

[wiebe@CARYA]

>>That sounds like this VI.

>Where'd you find that?

Scripting. New VI Object.

[AristosQueue (NI)]

> That sounds like this VI.

Unreleased primitive because, yeah, it is unstable in some corner cases. The function was added to LV in order to play around with different allocation strategies. I thought it was not scriptable.

[wiebe@CARYA]

>I thought it was not scriptable.

Don't worry, it almost always breaks the wire (only a DVR with double works), and always breaks the VI...

[EthanStern]

> "it is unstable in some corner cases"

Corner cases that can be explained and avoided or corner cases that always leave a possibility of unstable code? Now I just want that VI to work.

[AristosQueue (NI)]

Ethan: I don't actually know, and I couldn't find details, just that there was "some reason" it never got released. My *bet* is that it has something to do with reallocation of refnums and the way LV avoids allocating an already allocated refnum, but that's just a guess.

[joshua.l.guthrie2.civ]

What I do.. good bad or ugly..

I create my object in an external VI, called via the Open VI, Run Invoke node.  After I make the object, I create the DVR and send the DVR back to the original VI via a notifier.  I then have a wait for event after the send notifier to keep the VI that I created the object and DVR from ever closing until I tell it to (and thus keeping LV's evil memory manager from nuking my precious data), and finally when triggered, i can then deallocate.

This now FORCES me to interact with the original object by reference with all the data safety of an in-place.  I use this for classes that comprise large data sets..  let's me do things like have an array of DVRs rather than deal with the array resizing hell of an array of class objects, etc.

Now, should there be a better way, you bet.  The graphical syntax of an in-place DVR and doing error handling right is insane, and a timeout function would be nice.

[drjdpowell]

rather than deal with the array resizing hell of an array of class objects

Just FYI, but when I optimized my "Messenger Library" to handle large messages (which are by-value objects), I found it critical to use Swap to avoid memory copies on building arrays.   I would build in an empty array, then Swap in to actual array.  Here it is as a Malleable VI:

[wiebe@CARYA]

> I found it critical to use Swap to avoid memory copies on building arrays. 

That is a shock...