agreed! Applications that lack explicit logic for handling heavy workloads (ie producers outpacing consumers for a sustained period) are the most common culprit for unresponsive desktop applications that become completely unusable.
relatedly: would not bounded but programmatically growable channels also make it trivial to provide a "unbounded" style channel abstraction? (not that i'm advocating that, merely that it seems like it would turn the unbounded channel abstraction into an equivalent one that is resource usage aware) On Fri, Dec 20, 2013 at 8:52 AM, György Andrasek <jur...@gmail.com> wrote: > On 12/19/2013 11:13 PM, Tony Arcieri wrote: > >> So I think that entire line of reasoning is a red herring. People >> writing toy programs that never have their channels fill beyond a small >> number of messages won't care either way. >> >> However, overloaded programs + queues bounded by system resources are a >> production outage waiting to happen. What's really important here is >> providing a means of backpressure so overloaded Rust programs don't grow >> until they consume system resources and OOM. >> > > While I disagree with the notion that all programs which don't have their > bottlenecks right here are "toys", we should definitely strive for the > invariant that task failure does not cause independent tasks to fail. > > Also, OOM is not free. If you manage to go OOM on a desktop, you'll get a > *very* unhappy user, regardless of their expectations wrt your memory > usage. Linux with a spinning disk and swap for example will degrade to the > point where they'll reboot before the OOM killer kicks in. > > Can we PLEASE not do that *by default*? > > _______________________________________________ > Rust-dev mailing list > Rust-dev@mozilla.org > https://mail.mozilla.org/listinfo/rust-dev >
_______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
