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.
My general feeling is that providing both bounded and unbounded channels would be good. Even better would be allowing for different ways of handling bounded channels (e.g. block on send, drop messages, etc.), but I imagine that providing only one type of bounded channel (using block on send if it's full and providing a .try_send() that avoids blocking) would be sufficient (especially as e.g. dropping messages can be implemented on top of this type of channel). 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 On Dec 18, 2013, at 9:36 PM, Patrick Walton <[email protected]> wrote: > On 12/18/13 8:48 PM, Kevin Ballard wrote: > >> By that logic, you'd want to drop the oldest unprocessed events, not the >> newest. > > Right. > > To reiterate, there is a meta-point here: Blessing any communications > primitive as the One True Primitive never goes well for high-performance > code. I think we need multiple choices. The hard decision is what should be > the default. > > Patrick > > _______________________________________________ > 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
