On Dec 18, 2013, at 10:49 PM, Daniel Micay <[email protected]> wrote:
> On Thu, Dec 19, 2013 at 1:23 AM, Kevin Ballard <[email protected]> wrote: >> In my experience using Go, most of the time when I use a channel I don't >> particularly care about the size, as long as it has a size of at least 1 (to >> avoid blocking on the send). However, if I do care about the size, usually I >> want it to be effectively infinite (and I have some code in my IRC bot that >> uses a separate goroutine in order to implement an infinite channel). Upon >> occasion I do want an explicitly bounded channel, but, at least in my code, >> that tends to be rarer than wanting effectively infinite. > > It's not effectively infinite, because you can run out of memory. The > difference between a bounded queue and an unbounded queue is whether > running out of space blocks or aborts the process. The maximum > capacity doesn't also have to be the minimum capacity - that's just an > optimization used by some specific implementations and doesn't apply > to all bounded channels. > >> I also believe that unbounded should be the default, because it's the most >> tolerant type of channel when you don't want to have to think about bounding >> limits. It also means async send is the default, which I think is a good >> idea. >> >> -Kevin > > You do have to think about bounding limits. The limits just have to be > externally implemented instead of being enforced by the queue. It's > not a matter of whether send is synchronous or asynchronous but > whether or not the data structure ignores the possibility of running > out of resources. 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 _______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
