ThEvent.cpp

[Wolfram]

I found out how to get this error dialog. See attached VI-Lib.

Hope this will help someone to get rid of this error dialog when

exiting LabVIEW or the application you made.

Wolfram

[Aristos Queue]

QUOTE(Wolfram @ May 9 2007, 03:48 AM)

I found out how to get this error dialog. See attached VI-Lib.

Hope this will help someone to get rid of this error dialog when

exiting LabVIEW or the application you made.

Wolfram

Bug confirmed. I'm investigating. I'll try to get back to you before the end of the week.

CAR 49882DJ1

[Wolfram]

ZITAT(Aristos Queue @ May 9 2007, 04:06 PM)

Bug confirmed. I'm investigating. I'll try to get back to you before the end of the week.

CAR 49882DJ1

Hi Aristos Queue,

have you investigated this issue. I'm interested how it is going on.

Wolfram

[Aristos Queue]

Well, it took a while to dig into. But I (with help) found it.

Turns out to be a bug beyond just Notifiers. A refnum acquired by any VI or its subVIs is supposed to be released either by an explicit call to a primitive that closes the refnum or auto-closed by LV when the VI stops running. Well, for subroutine VIs, the auto-close just was never happening for all refnum types. The refnums were leaked. In the case of Notifiers, the problems you saw at exit was caused by trying to shutdown the notifier system with notifiers still in existence. Most refnums won't have the same crash behavior (in fact, Queues, which are tightly related to Notifiers, do not crash). But all of them leak.

Workarounds I can think of...

a) Call Release Notifier as part of your VI's execution so you don't rely on the auto-close

b) Make the subVI not be subroutine priority.

c) With the functional global, you could have an input on the conpane for Notifier In. When you pass Not a Refnum as the input, the functional global would use the value last stored in the shift register. If you pass a value, then that value would be stored and passed out as the output. This allows you to initialize your Notifier outside.

This bug will be fixed in the next release of LV.

[Jim Kring]

QUOTE(Aristos Queue @ May 17 2007, 11:56 AM)

A refnum acquired by any VI or its subVIs is supposed to be released either by an explicit call to a primitive that closes the refnum or auto-closed by LV when the VI stops running. Well, for subroutine VIs, the auto-close just was never happening for all refnum types. The refnums were leaked. In the case of Notifiers, the problems you saw at exit was caused by trying to shutdown the notifier system with notifiers still in existence. Most refnums won't have the same crash behavior (in fact, Queues, which are tightly related to Notifiers, do not crash). But all of them leak.

[...snip...]

This bug will be fixed in the next release of LV.

No!!!! I have entire software architectures based on exploiting this feature to create objects that are not garbage collected when the call chain goes idle!!!

Actually, I'm just kidding, but I'd really like to be able to have more subtle control over the lifetime of references

[Aristos Queue]

QUOTE(Jim Kring @ May 17 2007, 03:55 PM)

No!!!! I have entire software architectures based on exploiting this feature to create objects that are not garbage collected when the call chain goes idle!!!

Actually, I'm just kidding, but I'd really like to be able to have more subtle control over the lifetime of references

Simple! Create a LV2-style global that wraps around all "Open ..." and "Create ..." functions, returns the value to you in a variant (which you can then change to the specific data type). That VI should hold an FP reference to itself, intercept both the AppExit event and the PanelClose Event, and provide whatever clean up for the refnums. Disabling the Abort button is easy -- just have a loop in memory that polls for all open block diagrams/front panels in memory and clones a reentrant VI that itself doesn't show the abort button and have it float over the relative position of the abort button on each panel and diagram. Now all the holes should be plugged -- you can add ways to early dispose the refnums as needed by adding other actions to your LV2-style global.

Honestly, I can't believe OpenG hasn't already rolled out a tool to do all this.

[Jim Kring]

QUOTE(Aristos Queue @ May 18 2007, 09:40 AM)

Simple! Create a LV2-style global that wraps around all "Open ..." and "Create ..." functions, returns the value to you in a variant (which you can then change to the specific data type). That VI should hold an FP reference to itself, intercept both the AppExit event and the PanelClose Event, and provide whatever clean up for the refnums. Disabling the Abort button is easy -- just have a loop in memory that polls for all open block diagrams/front panels in memory and clones a reentrant VI that itself doesn't show the abort button and have it float over the relative position of the abort button on each panel and diagram. Now all the holes should be plugged -- you can add ways to early dispose the refnums as needed by adding other actions to your LV2-style global.

Honestly, I can't believe OpenG hasn't already rolled out a tool to do all this.

Sounds simple and elegant. I'll get right on it.

Actually, the work-around that I use, is to either employ a factory pattern, where there is a loop (factory) that does nothing but create object references (resulting from a message request and then messages back the reference to the requestor) and never goes idle, or I spawn an asynchronous VI that creates a new object reference, messages it back to the calling thread, and then waits indefinitely, for the reference to go invalid.