On Thu, Dec 19, 2013 at 1:23 AM, Kevin Ballard <ke...@sb.org> 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. _______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
