Carbage collector

[Tomi Maila]

Hi,

I got a an idea on how to implement carbage collection in LabVIEW. With carbage collection I mean closing stuff such as files after VI stops running. The concept is simple. Keep the stuff in an uninitialized shift register. As long as the VI owning the shift register is in memory, we have our stuff in memory and we can close them. To find out when our main VI has stop running, we can poll the functional global VI using dynamic calls. If the first run primitive is true inside functional global, then the main VI has exited.

Everything works fine in development environment. However in an EXE things get more complicated. Here is where I need your help. Any idea how to keep the functional global in memory after the main VI has exited so that the uninitialized shift register doesn't get cleaned up before carbage collection. In development environment functional global stays in memory but in exe it's automatically disposed. I can force the functional global front panel to open but it looks ugly. Are there any methods to keep VI in memory so that we don't have to show the front panel of the VI to users. I must remind also that this VI is not always running so we cannot use runtime properties of the VI only such as transparency.

Tomi

Carbage collector for LabVIEW 8.0

http://forums.lavag.org/index.php?act=attach&type=post&id=5082

[Aristos Queue]

I *think* that any code placed in the "App Exit" event case of a VI is guaranteed to have a chance to run before the application exits. That was certainly the intent of the design -- we don't "terminate with extreme prejudice" any VI until after there's been a chance for those event structures to execute.

[Jim Kring]

QUOTE(Tomi Maila @ Mar 1 2007, 07:54 AM)

Everything works fine in development environment. However in an EXE things get more complicated.

EXE's require at least one window to be open, otherwise they are terminated.

[Tomi Maila]

QUOTE(Aristos Queue @ Mar 1 2007, 06:10 PM)

I *think* that any code placed in the "App Exit" event case of a VI is guaranteed to have a chance to run before the application exits. That was certainly the intent of the design -- we don't "terminate with extreme prejudice" any VI until after there's been a chance for those event structures to execute.

Yes it does but it doesn't keep my shift register in memory as my VI is not running. Event case requires a running VI to work. Check the code...

Tomi

[JDave]

QUOTE(Tomi Maila @ Mar 1 2007, 08:16 AM)

Yes it does but it doesn't keep my shift register in memory as my VI is not running. Event case requires a running VI to work. Check the code...

So have the event case in the main VI that is holding on to your FGs. Have that event case then clean up the FGs before ending the event case.

[Tomi Maila]

QUOTE(dsaunders @ Mar 1 2007, 06:30 PM)

So have the event case in the main VI that is holding on to your FGs. Have that event case then clean up the FGs before ending the event case.

I think I was unclear with my question. The whole idea was to build libraries with different kinds of objects carrying external references that users don't need to explicitly close so that users could use them in a same way as they use normal value carrying wires. Creating these objects would launch carbage collector. Carbage collector would monitor the context and when nothing is runnig it would close all open references. It would make programming easier for users and help avoiding bugs. So anything that needs modifications to the main VI is not an option.

Aristos Queue proposed using App.Exit event. It seems that this event in LV 8.20 doesn't guarantee that the event is executed before non-running VIs are disposed. So at the time when this event gets executed in LV 8.20, my shift register content is already gone.

In an application build with LV 8.0 it doesn't even get executed (although I think the builder should be the same).

From Jim's answer I guess that the only possibility is to force the some of the VI front panels to stay open long enough so that carbage collector has done it's job. Keeping a front panel open keeps the VI in memory. But it's not nice to have a front panel open for functionality that should be invisible to the user, especially in a build applicaiton. If anybody comes up with a better idea, I really appreciate it.

Tomi

[jpdrolet]

QUOTE(Tomi Maila @ Mar 1 2007, 10:54 AM)

Hi,

I got a an idea on how to implement carbage collection in LabVIEW. With carbage collection I mean closing stuff such as files after VI stops running.

LabVIEW already does the garbage collection for you, such as closing files when the hierarchy that opened the file goes idle. Your Garbage Collector would only attempt to close refnums that are already invalid anyway.

[Tomi Maila]

QUOTE(jpdrolet @ Mar 1 2007, 08:00 PM)

LabVIEW already does the garbage collection for you, such as closing files when the hierarchy that opened the file goes idle. Your Garbage Collector would only attempt to close refnums that are already invalid anyway.

I'm not that rookie , although I'm fairly rookie compared to other users here . One example where I need explicit cleanup is when closing references to external file formats. Another example is an XML file where you want to write all closing tags to the file when closing the file. You may also want to clean up temporary files or close data base connection properly or send message to other application instance that we're closing up or... You get it.

Tomi

[jpdrolet]

Sorry for my short sight...

To prevent the main hierarchy from being unloaded before the garbage collector does its purpose, have Garbage Collector to open a VI reference to MainVI.vi. That will keep its hierachy in memory after it comes idle. Garbage Collector can itself have its FP open but in "hidden" state, see the Open FP method. I'm pretty sure that it will keep the application running without visible window.

[robijn]

QUOTE(Tomi Maila @ Mar 1 2007, 06:50 PM)

From Jim's answer I guess that the only possibility is to force the some of the VI front panels to stay open long enough so that carbage collector has done it's job. Keeping a front panel open keeps the VI in memory. But it's not nice to have a front panel open for functionality that should be invisible to the user, especially in a build applicaiton. If anybody comes up with a better idea, I really appreciate it.

Open a VI front panel from your library and set the state to Hidden. It will stay there although it is invisible and I think you can do with that what you want. It's a very good idea, I have to say. I tink I know what you're aiming at.

I don't really like garbage collection as in scavanging. I like the "right now" garbage collection better, as it fits real-time programming better. So when you don't use data or an object anymore, it is destroyed RIGHT NOW. Then you know where extra time may be needed (depending on the size of the object/stored objects/entire tree) and you can make arrangements in your prog for that extra time.

Joris

[Tomi Maila]

QUOTE(robijn @ Mar 2 2007, 04:20 PM)

I don't really like garbage collection as in scavanging. I like the "right now" garbage collection better, as it fits real-time programming better.

Any idea how to detect when a wire buffer is no longer used?

Tomi