In an interactive application, you probably don't want to allow the user to queue up 30000 actions that will then slowly get executed over the next, say, 10 minutes. That would mean there is an extremely large delay between taking a UI action and seeing the result of that action (because the other 29999 actions have to be handled before the latest one can be handled). That's also why some applications display a progress spinner and block you from interacting with the UI further (of course that's not always ideal either, you might want to have some small queue and optimistically update the UI already).

If they are just batch background tasks (i.e. there is no expectation of seeing some immediate UI update as a response), then having a larger queue might be fine. There's not really that much reason to put a (small) limit on say the number of files to be downloaded in a queue. And having a really large queue bound is not that dissimilar from having an arbitrarily large queue (limited be memory of course), in terms of buffer bloat and added latency.

> If they are just batch background tasks (i.e. there is no expectation of seeing some immediate UI update as a response), then having a larger queue might be fine.

"Larger" is not good enough; you really want an unbounded queue (unbounded in theory of course), because otherwise the GUI thread might block at some point. Unless you want to spend a lot of effort on exception handling (at which point unbounded is still the best choice, see below).

Also, unnecessary restrictions in your program might cause problems in the future when your software is ported to a larger architecture, or when demands change.

The point is there should always be appropriate backpressure. For a GUI, lockup would be inappropriate backpressure. More appropriate would be some interactive backpressure -- even a modal spinning wheel is better than queuing additional rage-clicks driven by user frustration at slowness, that are all wasted.

There are bo truly unbounded queues. As some point your application will start trashing swap or trigger OOM. Backpressure is always the right solution (but if course sizing queues is hard).

Why would it be preferable for it to be unbounded?

Bounds let you have a `try_push` function that can obviously fail, whereas with unbounded you can only really know it failed because of OOM, or your producer thread gets blocked.

When `try_push` failure happens you know something strange is happening in your code.

Unbounded can also have a try_push() functionality.

Unbounded is preferable because that's how we do everything else, and best prepares for porting to larger architectures. Do your strings have a maximum size, for example?

We have bounded queues because consumers and producers can consume at different rates. An unbounded queue will have the producer fill up main memory and then you need to do load shedding which turned the whole unbounded story into a lie.

In what circumstances would a ‘try_push’ fail on an unbounded queue? On a bounded queue it would fail when the queue is full.

The size of the queue can be read from a config file, and is tuned to the capability of the machine.

> In what circumstances would a ‘try_push’ fail on an unbounded queue?

When you have an out-of-memory situation.

The thing you are trying to express is that you want a queue that stops working only when it physically can't work. Putting arbitrary large numbers in config files is not the way to express it.

This doesn't seem correct. What if, for example, the long-running tasks would like to allocate memory, and they cannot because the user has clicked the button a few billion times? In that case, it seems like perhaps we should have accepted fewer jobs, so that we would be able to perform the ones we accepted.

If the only thing you need to allocate memory to is your queue, then maybe. Otherwise you'd incur in problems like the sibling comment. That's the very same reason you limit connection pools on applications that connect to a database: to prevent some instance to use all the database server connections and leave nothing to other instances.

So then your program gets killed. Using a bounded queue let's you handle these situations gracefully and then you can tie these errors to alerts, which are then tied to a scaling policy.

Does your device have infinite memory?