> Processes overloaded with too many > messages will slow down and grow in memory until they eventually exhaust > system resources and crash.
In Erlang this is true, but Rust semantics are different. Memory is certainly consumed but there is no mailbox scanning like Erlang nor is there anything like Erlang's physically separate heaps. There is also no garbage collection by default. The risk here is unbounded memory use. The size of the messages waiting on a port does not affect performance as in other systems (aside from those stemming from lack of memory). > 1) Drop messages on the floor: This falls into the category of "at most > once" message semantics that actor systems are typically described as having > (although there's a fun discussion about this right now on the friam mailing > list). My personal opinion is that systems that can tolerate the loss of > messages are more robust by design This is unsuitable as a general purpose mechanism. Whether this is appropriate is highly application specific. > 2) Crash the sender: This works similarly to the above in that it results in > the messages being discarded, but can loop in Erlang-style fault tolerance > to recover from an overloaded system. I definitely find this less preferable > than simply dropping messages on the floor though. This is a particularly > invasive option that I think doesn't translate well to distributed systems. Rust does not have supervisors and failure recovery features that Erlang has. It would have to grow these for this to be really viable. If you did this in a callback from a C FFI you'd have to abort the whole process. > 3) Make sends to a full channel an error: I'm really not a fan of this > option at all but I'm listing it for completeness. We could make everyone > check every message send for success. Ick. No thanks. What should the default be? This makes the API a lot more complicated. There is a solution 4, which is the old proto! stuff, which created bounded protocols, but bitrotted. I think this is probably what you're really looking for. Opting into #2 or #3 seems like it might be useful. I'm not sure I have formed a complete opinion yet, but thought I'd present some of the counter arguments. jack. _______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
