Getting a ref to a clone VI inherently unsafe?

[David Boyd]

I was browsing through class code from the Actor Framework (ashamed to say I haven't used this framework, yet, but that's changing), and stumbled across what appears to be a dire warning.  (See the attached,

or if you'd rather, read the BD comment here.)

Quote

 

Obtaining a reference to a clone VI is an unsafe opeation that can cause LabVIEW to crash. LabVIEW was never designed to allow this, and it is possible only because of an oversight in Open VI Reference that went unnoticed for many years. However, opening a reference, using it for a limited set of operations, and closing it quickly is safe enough to use for a debugging tool. National Instruments recommends you avoid doing this in applications meant for your end users.

If you use this technique elsewhere, please replicate this advisory message.

 

 

I've used an architecture for years now where I launch N clones of a VI using the ACBR in fire-and-forget mode, and subsequently the clones get a VIref to themselves and register that (with an assigned index) by message back to a GUI VI.  The GUI then allows the user to switch through the clones' FPs to be shown in a subpanel.  I've never had an issue traceable to this.  Note that in my code, the clone refnums are NOT obtained by an Open VI ref with clone name string (as shown) - they are implicitly obtained within the clones via a VI class property node.

Does this warning imply that this architecture is somehow unsafe?

I'm hearing AQ's authorship in my head when I read this warning.  @Aristos Queue, are you listening?  Can you comment? (Apart from chastisement for my only now learning about the AF - sorry.)

 

Dave

[Neil Pate]

I think the warning is related to the Open by name. I really hope so as I too use the technique you describe where the clones themselves get their own references so that they can insert themselves into a SubPanel (and do other stuff to the FP like title etc). Been using this architecture for five or six years now and never had any run-time crashes I can think of.

 

[hooovahh]

I asked a similar question a while ago and Dr. Powell chimed in with what he believes it means.

EDIT:  Oh and a thread where AQ explains that having a clone reference doesn't keep the main VI from leaving memory.  If it does it will close the clone references that you still have a handle on and can cause crashy.

[David Boyd]

Thanks, @hooovahh, for pointing me to those older discussions, which I probably totally missed. @drjdpowell's comment about a clone's reference having guaranteed validity when passed to its subVIs doesn't seem to apply to my/@Neil Pate's use case - we're sending a cloneVI ref to another VI via messaging.  So no telling when the original VI ref might go out of scope.

And I just realized that my demo code for launching off clones (and then later gathering their refs for subpanel use), explicitly closes the original VI ref after they're launched.  There is still a static ref on the caller's BD though - I think there has to be since you need a strictly typed ref to make the ACBR work at all.  My demo code is below.

 

Dave

[Neil Pate]

Now that I think about it, I also cache the This VI ref in another VI which I use as sort of an actor debugger to allow me to open the FPs and BDs of any running actors including clones (not AF actors, my own home rolled framework). I poll all the refs multiple times per second to get status about the clone name and running status, and have never seen any weird crashes which I have attributed to that. 

[drjdpowell]

I don't believe a this-VI ref has any problem; it is only a ref openned by name.  Example, if I openned a reference to the string "MyVI.vi:6", then clone 6 of MyVI could leave memory without properly closing the ref.  

[Aristos Queue]

The open by name was never intended to work. The problems crop up when you open a VI ref to a clone and then that ref outlives the clone itself. I personally rely upon this technique for several of my debugging tools, so I tried to stabilize the situation, but I couldn't really close the holes. As long as you make sure that you are closing the VI refs that you open before the clone VI has a reason to leave memory, LV seems to be fine; if you have the ref open and you close out the clone, then you try to do something with the ref, that's when problems occur.

 

@drjdpowell wrote:

> I don't believe a this-VI ref has any problem; it is only a ref openned by name. 

Correct.