Avoid Reference Garbage Collection?

[opejumeys]

I'll throw in my vote to get this behavior changed in the garbage collection.

We often use queue references in an FGV.  This is convenient so that we can easily find anything that references the queue by doing a subVI search instead of a string search (which is often unreliable).  It also helps that we don't have to close references since you are really only opening a single reference and using it everything.  If you open the queue reference by name, you are creating a new reference every time and have to close it, or potentially cause a memory leak with the build up references.

In LV2016, the queue reference in FGV worked great.  Upgrading to 2017, the queue is destroyed when the first VI to call the FGV stops executing...even if there is another active reference to the FGV or even if the queue has data in it.  To me this is potentially a huge risk for data loss if you don't know exactly what you are doing.  I don't like the change at all.

[Jacobson-ni]

---

@opejumeys@opejumeys wrote:

In LV2016, the queue reference in FGV worked great.  Upgrading to 2017, the queue is destroyed when the first VI to call the FGV stops executing...even if there is another active reference to the FGV or even if the queue has data in it.  To me this is potentially a huge risk for data loss if you don't know exactly what you are doing.  I don't like the change at all.

---

I would be interested in seeing an example like this which works in 2016 but not 2017. To my knowledge, this type of behavior was not changed but it would be good to know about if it did.

[rolfk]

---

@opejumeys wrote:

In LV2016, the queue reference in FGV worked great.  Upgrading to 2017, the queue is destroyed when the first VI to call the FGV stops executing...even if there is another active reference to the FGV or even if the queue has data in it.  To me this is potentially a huge risk for data loss if you don't know exactly what you are doing.  I don't like the change at all.

---

That doesn't quite sound right. Something in your code must be different than what you describe, because all refnums in LabVIEW are destroyed when the hierarchy in which the refnum was opened/created goes idle and that has been so since the advent of refnums in LabVIEW 2.5 or even earlier.

[TurboPhil]

"all refnums in LabVIEW are destroyed when the hierarchy in which the refnum was opened/created goes idle and that has been so since the advent of refnums in LabVIEW 2.5 or even earlier."

I *think* that is not 100% true. I believe I was told that if you open multiple references to a *named* queue, then LV will refcount and only destroy it if all referrers's call chains have gone idle. So I think if you created a non-reentrant FGV to hold a reference to an *unnamed* queue, then it would be destroyed as soon as the call chain of its creator stopped. But if you made that FGV reentrant (not something one would expect to do for functional globals, but doable in this particular instance), and had each clone open a new reference to a *named* queue, then you could gain some of the refcount protections.

But, again, i should caveat:

• that is something I was told anecdotally, so I cannot confirm if the refcounting actually works like that
• even if you moved to the reentrant, named-queue FGV pattern, it would be far from foolproof

So not really offering a solution to the problem. But *perhaps* an explanation of perceived behavior change.

[rolfk]

---

@TurboPhil wrote:

I *think* that is not 100% true. I believe I was told that if you open multiple references to a *named* queue, then LV will refcount and only destroy it if all referrers's call chains have gone idle. So I think if you created a non-reentrant FGV to hold a reference to an *unnamed* queue, then it would be destroyed as soon as the call chain of its creator stopped. But if you made that FGV reentrant (not something one would expect to do for functional globals, but doable in this particular instance), and had each clone open a new reference to a *named* queue, then you could gain some of the refcount protections.

---

It is true! As alluded earlier in this thread you need to distinguish between a refnum and the (named) object it refers to. You can have multiple refnums that reference the same named queue. As long as one of these refnums is open, the queue will be kept alive. But the refnum itself still will be auto collected as soon as the top level VI in whose hierarchy it was created goes idle.

[opejumeys]

---

@Jacobson-ni wrote:

---

@opejumeys@opejumeys wrote:

In LV2016, the queue reference in FGV worked great.  Upgrading to 2017, the queue is destroyed when the first VI to call the FGV stops executing...even if there is another active reference to the FGV or even if the queue has data in it.  To me this is potentially a huge risk for data loss if you don't know exactly what you are doing.  I don't like the change at all.

---

I would be interested in seeing an example like this which works in 2016 but not 2017. To my knowledge, this type of behavior was not changed but it would be good to know about if it did.

---

I did a double check on my code that this is happening.  We noticed the issue after we upgraded to 2017 (we actually upgraded from 2015, not 2016).   There were some other issues that resulted in adding some extra debugging code. Most likely this issue existed before, but was not identified until we upgraded.

I tested it in 2016 and 2015 with a brief example and the issue still shows up.