Get Queue Status function return elements default is set to = F. Should be set to = T.

[PaulG.]

The Get Queue Status function will return all the elements in the queue - if you remember to set the "return elements" bool input to True. It's set to F as default. Why would I not want all the handy information from Get Queue Status but not want the elements?

[dthor]

Perhaps it has something to do with memory? I really don't know, I don't use queues as often as I should.

If it defaults to False, then I assume labview has to do less work when the program runs.

[PaulG.]

I understand your point. Maybe it's my lack of understanding of how LV manages data output from primitives. However, the data are already present. And if you don't want the elements (and don't hook up a wire or indicator to the output) LV would not have to do anything differently.

[tst]

I'm voting for this because even though I'm already used to it, I agree that this is a mistake which is way too easy to make.

That said, if the change is made, then the primitive should have additional code which sees whether the elements output is wired or not and only takes the elements if the input is T AND the output is wired.

[SteenSchmidt]

I often use the Get Queue Status to check if an element has been dequeued by the recipient (handshaking), or to monitor the number of elements to determine when to dequeue all elements (queue as buffer). In neither case do I want the elements themselves. Since the elements also remains in the queue, an actual data copy takes place if you use Get Queue Status to peek the queue. This can be expensive.

But the primitive should definitely have an internal check to save the data copy if the elements output isn't wired and return elements? is set to True (no matter the default value of return elements?).

Cheers,

Steen

[Wart]

I typically use get queue status to get the number of elements in the queue.  Then I compare this number to an outragiously large number and alert the user if it gets too large (i.e. something is wrong).  It makes for a nice bit of error checking in another loop.  I'm not sure I've ever changed the return elements input to true.

I agree with tst.  Ideally it seems like if the elements output is wired it should return the elements.  Otherwise it shouldn't.

Edit: It looks like SteenSchmidt beat me to most of these points.

[AristosQueue (NI)]

As the designer of the queue prims, let me chime in on this.

Copying all the elements in the queue is expensive. You have all the elements in the queue and you make a duplicate of all of them when copying out for the Status primitive. That takes time and memory which is undesirable if you don't actually want the elements.

If the terminal is unwired, obviously LV does not need to make this copy.  When we were designing those prims, our first design had that. What we found was that there were cases where someone sometimes wanted the elements and sometimes not, and deciding based on whether the terminal was wired or not was a poor solution because that meant dropping a Case Structure and putting two copies of the Queue Status prim, one in each frame, where one was wired and the other wasn't. Ugly. So we introduced the boolean terminal.

I don't have a clue why we picked False for the default value. I just don't recall. It's something that could be changed in future LV versions if we mutated existing VIs to compensate (it's a bit harder than just creating an input boolean to preserve the input value; we'd also have to do something if someone does have the elements terminal wired for some strange reason). If you wire the terminal, then you would get the elements by default, which does, I admit, seem more reasonable. This would not create any performance hit for anyone who left the terminal unwired since the terminal being unwired would still be a reason to not copy the elements.

[Mads]

To me it makes perfectly sense to have it default at False. Most often when I use this function I want the que info, not the elements.  I would not want to spend any processor time or memory on generating that output when it is not needed.

The fact that you can get the elements out this way is not obvious enough to make users think that they should get it without any action. The compiler might rationalize the operation so that it would not matter if the default was true when the output has not been wired, but it is still logically cleaner to keep it at false.

I would agree that it would be useful to have a Preview function that returned all the elements though. Just remove that possibility from the get info operation (handle backwards compatibility the same way file operations did when they changed) and add a preview all function (or expand the functionality of the existing preview function (with a length input?)).

[AristosQueue (NI)]

Separating into two separate primitives opens the door to race conditions in those times when you wanted the full state of the queue.

[Mads]

Yes you would not be sure that the state you read with the get status was still valid when you read the data.

[SteveChandler]

My gut reaction is no for one simple reason. Changing the behavior of these prims will alter existing code. I don't mind development functionality being changed. But when it comes to altering runtime functions it kind of spooks me. Aristos Queue's comments make me feel a little more comfortable about this particular one.

So kudos!