Jump to content

Getting a ref to a clone VI inherently unsafe?


Recommended Posts

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

Open BD from AF Debug.png

Link to comment

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.

 

Link to comment

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

Clone launch w ref return and subpanel use.png

Link to comment

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. 

Link to comment

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.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.