If you're pushing to an unbounded vec in a tight loop you've got
fundamental design issues. If you're pushing to a channel, you've got
something like a server under load. Use cases matter.
About the deadlock scenario, why aren't non-blocking sends sufficient to
address that concern? I'd personally argue just as strenuously as for
bounded channels that robust systems shouldn't have
senders that block indefinitely (nothing like waking up to a production
server that's hung on a socket someone removed the timeout from).
Also, again: unbounded channels aren't, their bound is just arbitrary and
they fail catastrophically when it's hit.
Even if you don't OOM, channels that are too large are themselves a major
problem. If you actually use your hardware you only have so much capacity.
If your channel's getting backed up it's probably for a reason; when that
reason gets resolved you're going to need to go back to handling your
normal load plus everything you've been back-logging on your unbounded
channels. That's one of the main things you tune with bounded channels:
how backed up can this reasonably be before I just can't catch up anymore?
In a browser, users might not want you to throw away events, but they
probably don't want to deal with their browser OOMing, or pausing for five
minutes and then machine-gun responding, either. Again, anytime consumers
lag producers, you're screwed. The question is, how can you respond to
mitigate?
On Tuesday, December 31, 2013, Patrick Walton wrote:
> On 12/31/13 3:15 PM, György Andrasek wrote:
>
>> On 12/31/2013 10:41 PM, Patrick Walton wrote:
>>
>>> Unbounded channels have defined behavior as well. Undefined behavior has
>>> a precise definition and OOM is not undefined behavior.
>>>
>>
>> OOM is not a behavior. It's a DoS attack on the rest of the system.
>>
>
> When we speak of eliminating undefined behavior in Rust, we aren't
> speaking of taming code like:
>
> let mut v = ~[];
> loop {
> v.push(1)
> }
>
> Eliminating this hazard simply isn't one of the goals of the language.
>
> Patrick
>
> _______________________________________________
> 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
