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.