Dynamic call of class member VIs. Bug or feature ?

[Mithrandir]

In our company we are currently working on a pluginsystem for Labview using LVOOP as reference implementation. Now I've found a strange behaviour in the dynamic instanciation process. We call a "create.vi" of the class we want to have by reference and get the interface of it back. We can work with the class normally using the interface, but when all's done an the class was destroyed , the "create.vi" is of course also closed, so nothing of the class is used any more, the "create.vi" of the class still stays in memory.

That's a big problem, because we whanted to make the plugins replaceable while the main program is running, which of course can not be done if these vis do not unload.

BTW it's not important if i work with the class, the simple call of Open VI Ref let stay the vi in memory even if it was closed again imediatly afterwards

any suggestions to solve that problem?

PS: My first post in this marvelous forum :beer:

[Mellroth]

That's a big problem, because we whanted to make the plugins replaceable while the main program is running, which of course can not be done if these vis do not unload.

BTW it's not important if i work with the class, the simple call of Open VI Ref let stay the vi in memory even if it was closed again imediatly afterwards

How do you open your references, can you upload an image or some code to show us?

/J

[LAVA 1.0 Content]

Hi,

I wrote a plugin system with classes that works fine. Each plugin has a class deriving from a parent interface class. Each plugin class has a dynamic create method. In addition each class has a VI that simply returns a plugin class constant that is outside the class. If you dynamically open reference to correct plugin class constant VI, you get the correct plugin for you program. I search the directory structure for these plugin contant VIs so that I can at runtime search all available plugins and allow user to select which plugin shall be used.

-jimi-

[Mithrandir]

Yes, that's not the problem. I do exactly the same way as you do, but what i wanted to achive is that a plugin can be updated while the rest of the software keeps running.

lets say i have a class called ComponentImplementaton that represents my plugin, and i access it throu the class ComponentInterface.

further lets asume i have an application that should not be restartet because updates belonging to plugins. the only action should be to reload the plugin but as it seems that is not possible because once a plugin was loaded the class remains in memory.

do you know any methods to force the load from disk ( as the Labview IDE can) ?

i have attached my testings.

Download File:post-1256-1161250951.zip

[LAVA 1.0 Content]

Yes, that's not the problem. I do exactly the same way as you do, but what i wanted to achive is that a plugin can be updated while the rest of the software keeps running.

Ah... ok. Sounds stupid if you cannot unload a class. If you can accept changing the plugin class name, try adding version number directly to the class name. As an example MyPlugin.10.lvlcass.

There are also some methods in Application that you may try:

Application.LVClass.Open

Application.Library.Deploy/Undeploy (Class "Class" is a child of class "Library")

[Mithrandir]

Application.LVClass.Open was my first idea, but had also no success

Now I've tried your second option, but the vis still keep staying in memory (but no errors from the invoke nodes)

i think version numbers in the class name is possible, but only a workaround, and of course the old version will still stay in memory using up space.

nevertheless, if updates do not happen frequently this might be an option.

thanks for all help

[Aristos Queue]

any suggestions to solve that problem?

I know why you're having the problem, and you're not going to solve it easily.

1) A class stays in memory as long as there are any instances of the class in memory. Get rid of all instances of the data and the class will be able to leave memory. This means any control or indicator whose current operating value is the class value would need to be reset, and all the little copies hiding on terminals across the block diagram. About the only ways to clean it out are a) run the VI again with a different class that overwrites the previous execution (tricky since you have to hit all the same code paths) or b) unload the VI from memory. Why does it stay in memory? Because all those instances of the data need the class definition to be able to be copied, modified and even deallocated correctly.

2) A class stays in memory if there is a dynamic dispatch call to its parent class if those VIs are running. Remove from memory any VI that is calling the parent class methods. Why does it stay in memory in this case? Because we don't know what sort of flattened strings might represent your class data that you might be about to unflatten.

The only solution is to make your system really dynamic so that you dynamically load the parts relevant to classes and when you want to unload you unload all those VIs, then load again with the new set of classes.