[rust-dev] RFC: New Rust channel proposal

Eric Reed ecreed at cs.washington.edu
Tue Jan 14 14:35:15 PST 2014

I'm skeptical about combining Chan and SharedChan. Maintaining that
distinction is useful for expressing the programmer's intent and would
certainly make any analysis that cared to distinguish between single and
multiple producers easier to implement (off the top of my head, knowing
you're the only one with a Chan means you don't have to deal with potential
race conditions arising from interleaving of messages from different
producers). Maybe a SharedChan should be constructed by consuming a Chan
and upgrading its queue rather than duplicating all of Chan constructors?

Otherwise I'm fine with this proposal.

On Mon, Jan 13, 2014 at 6:48 PM, Brian Anderson <banderson at mozilla.com>wrote:

> In light of the general consensus that unbounded channels are not so hot,
> here's a new proposal for how Rust's channels should operate. This is based
> on the following assumptions:
> * Running out of memory is an awful failure mode for debugging.
> * Choosing an appropriate bounded queue size is hard.
> * Dealing with backpressure is hard.
> * Most channels are not filled without bound.
> This proposal has two facets: making the current channels appropriate for
> more use cases; adding additional channel types for specialized use cases.
> I'm still operating under the premise that there should be a "default"
> channel type that can be successfully used in most instances, and people
> should only need to pick something else when their message passing behavior
> calls for it. Not all of these recommendations are about resolving the
> unbounded channel debate.
> # Changes to `Chan`
> Firstly, let's combine `Chan` and `SharedChan`. This is partly to free up
> some of our complexity budget to add more channel types, and partly a
> concession to usability. A cloned channel will automatically upgrade itself
> to a multi-producer queue. This will add a small amount of overhead to
> various operations.
> Secondly, in order to accommodate the very common case where a channel is
> used just once, we optimize the single-send use case to not allocate.
> Essentially, we store a single element directly in the shared state between
> the channel and port. This restores the `oneshot` functionality we lost in
> the last channel rewrite. Again, this will add a small amount of overhead
> to some operations, though possibly not above the overhead incurred by
> combining `Chan` and `SharedChan`.
> Finally, my main suggestion about how to deal with OOM, let's put an
> arbitrary bound to the size of the queue on `Chan`. This isn't to say let's
> turn `Chan` into a bounded queue (which is difficult for implementation
> reasons), but instead that we add a feature that helps debug when you've
> actually chosen the wrong kind of channel because your producer sends
> without bound.
> When you hit this bound the send will fail and you know that you need to
> think harder about the behavior of this particular channel. If you *really*
> want an unbounded channel then you can construct it with `Chan::unbounded`,
> otherwise you pick ...
> # Synchronous and bounded channels
> Let's add `SyncChan` which is a bounded multi-producer single-consumer
> queue backed by a ring buffer. This supports `send`, which blocks by
> default, and `try_send` which returns an enum representing whether the send
> succeeded, the channel is full, or the channel is closed (the last two
> cases returning the message). In the special case where the channel bound
> is 0, we don't use a ringbuffer and just do a rendezvousing send and
> recieve. The default bound is 0.
> Comments?
> Regards,
> Brian
> _______________________________________________
> Rust-dev mailing list
> Rust-dev at mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20140114/82c8ddbf/attachment.html>

More information about the Rust-dev mailing list