On 12/18/2013 10:23 PM, Kevin Ballard 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.
In a working system, "effectively infinite" means the sender uses up
its timeslice before exceeding your latency goal, and the receiver
empties the channel before its timeslice is used up. In a failing
system, it means unpredictable performance or behavior.
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).
More choice is always better, except when you have limited resources.
We always have limited resources, so we consider priorities.
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.
There are different definitions of tolerant, as there are of simplicity.
Usually it's better to fail in ways that are easy to understand and fix.
This is the same lesson we learn from garbage-collected memory systems.
Nathan Myers
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
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
