07-24-2016 12:11 AM
08-14-2018 03:26 PM
Zombie Thread arise!
I wonder if LabVIEW specific design patterns have been created to deal with this?
I was pondering a pain point we have today in our code:
We call a plugin vi dynamically and close it afterwards. That plugin creates a DVR I will call DVR 1 and passes back data in DVR 1. In order to not loose it we copy the data out of DVR 1 before closing the plugin, put it in a new DVR 2 and pass it up the hierarchy, where it eventually gets copied again into another DVR 3 where it is put into our application wide data store. At different times in the program the global data store gets read and DVR 3 accessed. We have to be careful to not delete DVR 3 since it's widely used. Sometimes we need to copy the data and create new temporary copies for use in local places and then clean up that local copy.
We've been thinking we want to get away from clusters with DVR's in them and move to classes which represent data. But how DVR's live in those classes and specifically when those DVR's will just disappear on us is frighting. It could lead to us making methods that copy a class for the sole purpose of creating a DVR from a new layer of the call hierarchy.
Anyway, I feel like surely someone has thought about all this and probably written a paper showing design patterns on how to make LabVIEW program's that use DVR's without loosing data or leaking memory and while encapsulating all the details. Is that too much to hope for?
08-14-2018 08:03 PM
Has anyone ever tried to configure the FGV call setup to " Load and retain" and is the FGV using an USR or a globally initialized FBN?.
Subtle differences.
08-15-2018 05:31 AM - edited 08-15-2018 05:48 AM
@Thomas_robertson wrote:
We call a plugin vi dynamically and close it afterwards. That plugin creates a DVR I will call DVR 1 and passes back data in DVR 1. In order to not lose it we copy the data out of DVR 1 before closing the plugin, put it in a new DVR 2 and pass it up the hierarchy...
Why are you using DVRs instead of by-value data for these short-lived processes that only need to return data?
If you do need DVRs, create them in the Caller and pass them into the plugin.
08-15-2018 07:41 AM
@drjdpowell wrote:
@Thomas_robertson wrote:
We call a plugin vi dynamically and close it afterwards. That plugin creates a DVR I will call DVR 1 and passes back data in DVR 1. In order to not lose it we copy the data out of DVR 1 before closing the plugin, put it in a new DVR 2 and pass it up the hierarchy...
Why are you using DVRs instead of by-value data for these short-lived processes that only need to return data?
If you do need DVRs, create them in the Caller and pass them into the plugin.
Agree that this case sounds like by value could work.
If you actually need DVRs, another option is to create a an API that includes a daemon that creates the DVR, and returns it to the caller - then the daemon just sits and waits until it is explicitly closed through the API.
08-16-2018 09:18 AM
connector panes for plugin's where fixed years ago, so, it is what it is.
However, within our program we have freedom, that's why I'm intrested in design patterns for objects that use shared DVR's.