What is the purpose of the "max queue size" input of "Obtain queue"?

[Kjell-E]

What is the purpose of the "max queue size" input of "Obtain queue"?

In the documentation it says:
"Note max queue size only limits the number of elements in the queue. It does not preallocate memory. Therefore, resizable data types such as paths, strings, arrays, and so on can still increase and decrease the overall queue size."

...so... when the default is -1 = "unlimited" and setting a number does not result in pre-allocation of memory, what could possible be the advantage to bothering with this input at all??

-Obviously, it must serve some function or other that I have not thought of... hence this post.

Could it be that it -does- preallocate memory IF the data-type "supports this" (e.g. a type with constant size, such as "unsigned int8")?

[tst]

If, as the documentation says, the function does not preallocate memory (and I'm inclined to believe this is so), then the answer is probably exactly as it appears in the documentation - it "limits the number of elements in the queue". Some people may want to have a queue with a limited number of elements (although I can't think of an appropriate case off hand).

[EdDickens]

All it does is limit the number of elements in the queue.

I've used this a few times when I've needed to stop reading the queue for some reason and I don't want the queue to continue to fill with hundreds or thousands of items that I don't care about while I'm not reading from it. When the queue hits it's max limit of elements, the writer stops and waits for room to be available in the queue. This is helpful when passing large data types, like waveforms through the queue. This prevents unneeded dynamic memory allocation.

The overall queue size they are talking about is it's memory foot print. A queue with 10 elements of an I32 array will take twice as much memory as an array of I16, given that both the arrays have the same number of elements.

Ed

[CoastalMaineBird]

what could possible be the advantage to bothering with this input at all??

It has less to do with memory management than with your program logic.

It might make sense for you to have a limit on the number of jobs this queue can handle.

If the size is -1, then any ENQUEUE ELEMENT operation will succeed immediately (assuming you don't actually run out of physical / virtual memory).

If the size is N, then an ENQUEUE ELEMENT operation, when the queue is full, will wait for some specified time. If a slot in the queue does not become available in that time, the ENQUEUE ELEMENT will return an error. If a slot does become available, it is used.

[falkpl]

I agree with CoastalMaineBird,  queue limits are implemented to signify that a dequeuing (or the queue itself) has some limited resource.  This is somewhat like going to the movies, when they stop anyone from entering the line once it is longer than the number of tickets that can be sold.  In most cases the resources (usually memory or some I/O resource) is large on current systems and is not a problem.  I have used the queue limit for simulation to simulate a limited resource (even though there is no physical limitation) so it a nice feature to have even if you never use it.

Paul