Default timeout on queue write to 0 ms

[Robert_Hoffman]

The default timeout of a queue write primitive is set to -1 right now, which means that it waits forever to insert an element.  I am sure there are intstances where this is the right behavior, but for virtually all the cases that I have come across, I don't ever want that primitive to hold up operation of my code.  Whether running in RT or on a Windows machine, simply mimicking the behavior of the RT FIFO primitives would seem to be much better.  If for some reason your queue has filled up (and you have set a size limit), you can wind up with a hung application and no real way to fix it.  Right now, I have to remind myself to go in and set the timeout to 0, which works but can be tedious.

So, I vote to change the default timeout to 0 ms.  Not sure if it makes sense on the queue read or not, but for sure on the write side.  Thoughts?

[tst]

How often do you use fixed size queues? In my case, most of my queues are not bounded because I want to process all elements (meaning the timeout is irrelevant) and those that are bounded are usually used as circular buffers, meaning I use lossy enqueue, where the timeout is again irrelevant.

[crossrulz]

Just like tst, I have never ran into this situation.  What's the reason for using fixed sized queues?  And why would you want to not queue up the element?  That becomes lossy, my main reason for using a queue (it isn't lossy).

[Norbert_B]

I dare to say that this is never going to be changed. A change like this could easily break existant code functionality because it works differently in different LV versions.

And to add: The question about timeout for ENQUEUE is only existent for limited queues. If you limit the queue, but set a timeout to something different than "-1" (current default): What should happen once the timeout is reached?

Norbert

[SteenSchmidt]

Please don't change the default settings nor the current functionality of the queue timeouts. A whole heap of stuff will break. I don't use 0 ms more often than -1 - it depends on the specific logic you're implementing.

I most often use -1 ms on dequeue to avoid polling, except in the situations where I need to periodically "emerge" from the dequeue to check on something else. I just let the dequeueu primitive error out with code 1 or 1122 when the queue refnum goes bad.

Similarly with enqueue. For unbounded queues I most often use -1 as timeout, while for bounded I most often use 0 or another specific number fitting with the rest of the algorithm. But it varies. An unbounded queue can also get "bounded", sort of, by memory limitations mind you.

Cheers,

Steen

[tst]

Norbert and Steen, I don't think the reasons you are providing are relevant, because a) there's already a defined behavior for how a timeout behaves on a bounded queue and b) nothing will break because NI will use auto-mutation to change old code to have infinite timeouts.

Although, like I said, I don't think this idea should be implemented for the reason I gave earlier and also because it will conflict with other similar timeouts in LV which default to -1 and it will probably not be noticed by many people who think the old behavior still exists.

[Robert_Hoffman]

Thanks for the good discussion.  I can certainly understand the reasons given, and maybe this is a good chance for me to go back and review some of my old code and reasoning.  My primary goal was to prevent queues from holding up a thread in some unknown way.  Generally speaking, if I have a queue that is bounded, it is typically for memory considerations, and if it gets full it indicates something else is wrong in the application.  That is where the default timeout comes in.  Plus, I work with RT FIFO's all the time that have the default as 0, but they are bounded by their very nature.

All good points - Thanks for the input.

[AristosQueue (NI)]

The whole point of bounded queues (real queues, not the RT FIFO specialization) is to prevent a producer from flooding a consumer, and the -1 timeout is what you need to make the producer stall for a while. For any communication use cases, use the Enqueue Lossy, which doesn't have a timeout at all as it just kicks out the front of the queue to make space.

[Darren]

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