LabVIEW Idea Exchange

cancel
Showing results for 
Search instead for 
Did you mean: 
jdoyle

Enumerate active queues

Status: Declined

Any idea that has received less than 2 kudos within 2 years after posting will be automatically declined.

We have an application that extensively uses queues, both named and unnamed.  We suspect that one or more of these queues -- probably an unnamed one -- is not being properly drained, and over time is leading to a memory leak.  I would like a means to programmatically examine all the queues in use to determine whether any are growing without bound.  I looked for a way to do this and found this link.

 

The answer here is pretty unsatisfactory.  Our queues have a multitude of types, and replacing every get/release queue with a registration VI specific to that type would be very tiresome.  What we would like is a way to obtain a generic queue reference to each queue -- named or unnamed, suitable for use in Get Queue Status (providing the Elements Out output is not used, as that would require knowledge of type).

 

It would be fine if the refnums were "read only", that is, they could not be used to modify the queue in any way.  Come to think of it, read only refnums might be useful in themselves, but that's another post.

 

If anyone can think of a way to do this with the existing features of 8.6.1 or LV 2000, I'd like to know about it, but there seems to be no existing method for doing this.

6 Comments
AristosQueue (NI)
NI Employee (retired)

What you want is the Desktop Trace Toolkit.

http://sine.ni.com/nips/cds/view/p/lang/en/nid/206790

 

We wouldn't want to expose a generic interface to queues that you could actually use in a running application. That would violate the safety encapsulation of many VIs. A user can create an unnamed queue and use it within a single VI and be assured that the contents of the queue are always consistent. If we had a generic programmatic interface, malicious code could disrupt the functionality across VIs. Even a read-only reference creates thread-locking issues, and allows code to be written that had unforseen dependencies on other VIs.

 

The toolkit is a debugging system that can help you identify which queue is being enqueued and never being flushed/dequeued.

Message Edited by Aristos Queue on 09-28-2009 05:35 PM
Intaris
Proven Zealot

AQ, you beat me to it.

 

For exactly these security reasons I often use an unnamed Queue in any applications I ship to customers.

 

Seeing how you can piggyback any VI you want on an EXE, it's dangerous to leave Queues accessible within built applications.

 

If something like this would be implemented, then only for named queues please.

 

Shane.

crelf
Trusted Enthusiast
Totally - you want the Desktop Execution Trace Toolkit - it's saved us a bunch of time and money.




Copyright © 2004-2024 Christopher G. Relf. Some Rights Reserved. This posting is licensed under a Creative Commons Attribution 4.0 License.
jdoyle
Member

All,

 

Thanks for your quick response.  I already tried the Desktop Execution Trace Toolkit and found it unsatisfactory for reasons described in this post.

 

I would like to try it again with a larger MaxExents, but my 24-hour eval period has run out and I'm not likely to get authorization to spend $999 on a tool that croaked right out of the box.

Intaris
Proven Zealot

Talk to your local NI office, explain to them what the problem is and try to get a 1 week eval licence or something.

 

Message Edited by Intaris on 09-30-2009 06:28 AM
Darren
Proven Zealot
Status changed to: Declined

Any idea that has received less than 2 kudos within 2 years after posting will be automatically declined.