On Thu, Dec 19, 2013 at 3:57 AM, Kevin Ballard <[email protected]> wrote: > > Running out of memory can certainly be a problem with unbounded channels, but > it's not a problem unique to unbounded channels. I'm not sure why it deserves > so much extra thought here to the point that we may default to bounded. We > don't default to bounded in other potential resource-exhaustion scenarios. > For example, ~[T] doesn't default to having a maximum capacity that cannot be > exceeded. The only maximum there is the limits of memory. I can write a loop > that calls .push() on a ~[T] until I exhaust all my resources, but nobody > thinks that's a serious issue. > > There is definitely a use-case for bounded channels. But I don't think it > should be the default. If bounded channels are the default, then everyone who > uses a channel needs to have to think about what an appropriate bound is, and > in practice will probably just throw some small number at the channel and > call it a day. I expect most uses of channels aren't going to grow the > channel infinitely, and as such there's no need to require the programmer to > try and come up with a bound for it, especially because if they come up with > a bound that's too low then it will cause problems (e.g. performance > problems, if the failure case is blocking on send). > > If the channel does have the potential to grow infinitely, then the > programmer needs to recognize this case and handle it explicitly (e.g. by > opting into a bounded channel and determining an appropriate bound to use). > No default behavior will handle the need for bounded channels correctly for > everyone. > > -Kevin
Any producer/consumer situation where the input isn't limited can easily exhaust resources with an unbounded channel if the producer is given more CPU time than the consumer, or runs at a higher rate. _______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
