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]

>Or would there be a malleable primitive (a new static DVR) that could be dropped on a diagram and malleably adapt to any input type?

This.  

>I also want to support the use case where application scope (here I mean: what is getting launched...and when) is more dynamic than a top-level launcher can reasonably know.

You'd need to provide an example to convince me there is something that a standard tree-like hierarchy can't handle.  

Maybe you want something like Named Queues.  Where one Queue has multiple "owners", each with there own reference.  The Named-Queue lifetime is thus extends over the time the any such caller exists, rather than one specific caller.

[AristosQueue (NI)]

Ethan:

A workaround that exists today: You could use a named single-element queue instead of a DVR, with each caller getting the same named queue. Performance is essentially identical.

The idea of a static DVR reference is far more appealing to me than a "New DVR" node with a bool input. Currently, all dynamically opened refnums have the same rules for lifetime management, and I'd be loathe to change that if there is any other way, and the static DVR provides that other way.

Having said that, the static DVR wouldn't solve your malleable problem... unless we had a type input to the static DVR constant... which makes it pretty much equivalent to the solution you propose.

I see your problem, Ethan. I'm not happy with the solution you propose. But I don't see anything better. No kudos, just grumpy face.

[AristosQueue (NI)]

Here's the workaround code:

[wiebe@CARYA]

A queue isn't a DVR.

It will do the same thing for the program, but not for the developer.

If you stop a VI (during testing) between the dequeue and the enqueue the queue isn't unlocked.

As I only use DVRs when it can't be avoided (large data sets and therefor lengthy operations) the change of this happening isn't low.

[EthanStern]

Thanks, AQ. I think this does, indeed, work around my blocking issue with reference persistence. Funny enough, I started with named queues when I started picking at this problem years ago but wasn't clever enough to actually solve the problem.

"all dynamically opened refnums have the same rules for lifetime management"

100% agree that consistency within the language is important.

Another (perhaps better) solution to the issue driving my request is the ability to malleably perform async VI calls. If LV could open an asynchronous static reference to a malleable VI, I know many people who would use that feature. I don't see any issue with code intelligibility here and I do not think of it as an edge case. Your prior comment referring to a 'hypothetical node': https://forums.ni.com/t5/LabVIEW-Idea-Exchange/Asynchronous-Call-on-Malleable-VIs/idi-p/3765435

It's a bummer to look back at old feature requests from savvy early adopters, enthusiastically agree, and then realize that the feature was declined due to lack of interest from the community. For various reasons, it takes some of us a couple years to push the limits of new language features. Is there a proper process to revive an old idea (instead of reposting from scratch like I did here)?

[AristosQueue (NI)]

> If you stop a VI (during testing) between the dequeue

> and the enqueue the queue isn't unlocked.

Weibe: That's why I said a single element queue. You dequeue (without timeout) when you want to lock the data. You modify the value. Then you enqueue the data again. Anyone else who tries to dequeue will block until the enqueue is finished.

[AristosQueue (NI)]

> Is there a proper process to revive an old

> idea (instead of reposting from scratch like I did here)?

Nope. Repost as new idea, and then it'll either get re-closed as duplicate if the team feels like it's going to receive the same response as last time or let stand as open if it feels like the ground has shifted enough for it to maybe flourish this time.

[wiebe@CARYA]

>> If you stop a VI (during testing) between the dequeue

>> and the enqueue the queue isn't unlocked.

>Weibe: That's why I said a single element queue. You dequeue (without timeout) when you want to lock the data. You modify the value. Then you enqueue the data again. Anyone else who tries to dequeue will block until the enqueue is finished.

And that fails when the VI aborts between de dequeue en enqueue.

The enqueue will never happen, and all other code will wait forever.

Spoiler

You can use a single element queue for that, but you actually have to enqueue any locally created reference (a queue will do), and pull if the enqueued reference is still valid. If the VI is aborted, the reference becomes invalid, and other code won't be waiting forever.

Even this might not be air tight though.

[AristosQueue (NI)]

> And that fails when the VI aborts between de dequeue en enqueue.

Uh, yeah. Don't do that.

Sorry... not a use case I've ever dealt with.

[AristosQueue (NI)]

> And that fails when the VI aborts between de dequeue en enqueue.

And you shouldn't do that with a DVR either! If a VI unlocks a DVR and is midway through rewriting the value in the DVR (say the numeric goes through several math operations and you abort in the middle of them), and then you abort the VI, the value inside the DVR is *already modified*. It isn't "written back" to the DVR when the structure finishes. "In Place Element structure" means "in place" -- the value is modified as the code runs.

If you abort midway through an operation, you need to be very careful that the value you've computed is a valid one.