Okay, parallelism, of course, and I'm sure others. Bad use of the word 'only'. The point is that if your consumers aren't keeping up with your producers, you're screwed anyways, and growing the queue indefinitely isn't a way to get around that. Growing queues should only serve specific purposes and make it easy to apply back pressure when the assumptions behind those purposes go awry.
On Thursday, December 19, 2013, Patrick Walton wrote: > On 12/19/13 6:31 AM, Jason Fager wrote: > >> I work on a system that handles 10s of billions of events per day, and >> we do a lot of queueing. Big +1 on having bounded queues. Unbounded >> in-memory queues aren't, they just have a bound you have no direct >> control over and that blows up the world when its hit. >> >> The only reason to have a queue size greater than 1 is to handle spikes >> in the producer, short outages in the consumer, or a bit of >> out-of-phaseness between producers and consumers. >> > > Well, also parallelism. > > Patrick > > _______________________________________________ > Rust-dev mailing list > [email protected] > https://mail.mozilla.org/listinfo/rust-dev >
_______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
