lifetime of class attributes

[legrimpeur]

Dear all,

We have an application that spawns through VI Server several processes each one of them constructs a series of objects whose classes might share common ancestors and that might use the common ancestor class attributes and class attributes in general.   Now my question is what happens when those processes are relaunched without stopping the main application instance, will the class attributes values be preserved? If I stop the processes the G# debugger is telling me that this is not the case.   If the values are not preserved is the external create process the right way to achieve their preservation?

Forgive my ignorance: what is the purpose of the "open" methods and in which cases should I implement it? is it related to the external create process, do I understand right that all the object that are not implemented to support the external create process if created within this method will be owned by the external create process?

Thanks for your help

PS is there any special reason why the garbage collector and the preset DVR access structure disappeared form the palette? I personally found them very useful

Cheers  Andrea

[Mattias_Ericsson]

Hi Andrea,

Very good questions I must say. There are a few LabVIEW behaviours that need to be explained first, since G# is pure LabVIEW implementation. LabVIEW has its own garbage collector, as soon as the top-level VI stops executing that create e.g. DVRs, queues, TCP/IP connections. etc. these references is immediately invalid by LabVIEWs own garbage collector. But since G# is basically a LabVIEW class with a DVR+queue as class private data, all G# objects (DVRs and queues) will be garbage collected by LabVIEW and then kill the object. But if you build a large appilication with a lot of top level VIs executing in parallel (that can be started and stopped), it can be difficult and also really very annoying that you might get unexpected dead DVRs, queues and G# objects if the top level VI stops executing (it is not as in e.g. .NET where .NET knows if the reference is used or not), but ownership of references is everything in LabVIEW.

In order to get around this sometime quite unwanted behaviour and to keep objects alive, G# implements something we call "ExternalCreateProcess", which can be started with a G# helper VI (see Advanced palette). If this background process runs, all G#Objects will then not be created and owned by the top-level VI that runs the constructor method, but an event will be sent to the ExternalCreateProcess to create and own the object for me and then just return the reference back. Since all this behaviour is built into G#, you don't notice anything during creation. But the big difference is that objects will not be killed by LabVIEWs own garbage collector as long as the ExternalCreateProcess is running. ExternalCreateProcess is killed by the G#GarbageCollector. Make sure to execute this as the last step in your code.

This way you may create objects from any top-level application and then close the top-level application without objects is killed. Just run the G#Garbage collector at the end to close the process. You can also see in the G#Debugger if the ExternalCreateProcess is running or not, and also see which VI that is owning an object.

Regarding the class attributes, they follow the exact same behaviour as an object regarding lifttime, since class attributes are stored in a common class DVR. If the top-level VI that first accessed the class attributes stops executing, class attributes are garbage collected by LabVIEW. To solve this problem, use the ExternalCreateProcess and class attributes will not be garbage collected by LabVIEW. Notice that a class attribute exists even without any objects at all e.g. a static class is a class with only class attributes and no possibility to instance any objects. Only way to "kill" a class attribute is that the VIs who owns the DVR, which is the one that first accessed them or created an object of the class, will stop executing.

The G#Object_Open method is related to the above problem. If you use ExternalCreateProcess and create all your objects with this process running everything should be fine, right? Assume you create an object that holds a TCP/IP connection or some native LabVIEW reference. If you create these references in your G# constructor, they will also be owned by the external create process. No problems. If you don't want to create them at the same time you create your G# object, but perhaps later (when a user presses a Connect button or something like that), you  need to run the open TCPIP from a method, but the ownership of this reference will be the top-level VI that runs the method! The G#Object is owned by external create process, but not the TCPIP ref is not. What happens when the top-level VI dies? G# object is alive, but TCPIP is garbage collected. In order to get around this problem, the solution is G#Object_Open method. If you override this method in your class and have the External Create Process runnung, this VI will be excuted by the process and if you put your TCPIP open inside this override method, it will also be owned by the process. In other words, G#Object_Open main purpose is to allow you to create more reference after your object has been created in order to get the same owner, External Create Process.

The external background process actually solves a lot of problem that you would need to make some kind of own implementation to get around the problem with LabVIEWs built in garbage collector.

The palette issue -  Garbage Collector missing in VIP package? I simply forgot to put it there I assume, it is included in the non-VIPM distribution. Working with palettes is a real pain in VIPM. The DVR access structor is not included in the VIPM package, since I never could find a way in VIPM to add a code snippet to the palette.

Hope this clears out a few things,

Mattias

AddQ