On 12/18/2013 06:29 PM, Tony Arcieri wrote:
Some context:
https://twitter.com/mentalguy/status/284776872452173824
As someone who knows a lot of people who use Erlang in production
(Erlang has unbounded mailboxes), and the maintainer of my own
actor-based concurrency framework (Celluloid, which started with
unbounded mailboxes and is in the process of moving to bounded ones),
I have come to the Hard Won Knowledge(TM) that unbounded
queues/mailboxes/channels are a bad idea.
In terms of production users of these sorts of systems, my personal
experience is that nobody likes unboundedness and most have
experienced some sort of production outage because of it. This isn't
just a minor nitpick. This is the sort of decision that makes or
breaks the reliability of systems under load.
The main problem with unboundedness is that users systems based on
unbounded queues fail to adequately build mechanisms for providing
backpressure into their code. They then start flooding their systems
with messages, and get confused why they're performing so poorly when
the answer is they have a huge backlog of unprocessed messages.
Processes overloaded with too many messages will slow down and grow in
memory until they eventually exhaust system resources and crash.
Is anybody aware of existing analyses of the tradeoffs of bounded vs.
unbounded channels? I've always considered this a tradeoff between
unexpected OOM vs. unexpected deadlock (assuming blocking sends). Based
on some of your other feedback it seems like the tradeoff could also be
OOM vs. failure or dropped messages.
I'd like to point out that in the standard library our goal is just to
provide a dead-simple and fast default message passing type. There are
lots of interesting designs here, but things like disruptor can be done
outside std.
_______________________________________________
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
