On Dec 20, 2013, at 8:59 AM, Carter Schonwald <[email protected]> wrote:
> 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. That’s a pretty strong claim, and one I would have to disagree with quite strongly. Every time I’ve sampled an unresponsive application, I don’t think I’ve ever seen a backtrace that suggests a producer outpacing a consumer. -Kevin > 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 <[email protected]> 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 > [email protected] > https://mail.mozilla.org/listinfo/rust-dev > > _______________________________________________ > 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
