[rust-dev] RFC: New Rust channel proposal

Jeffery Olson olson.jeffery at gmail.com
Mon Jan 13 20:09:58 PST 2014

This is a great proposal, Brian.

I have no criticisms of the proposal itself, feeling that it's a
level-headed response to the previous threads on this issue.

But I do have a request (something I know Daniel Micay brought up in
#rust): What would it take to get shared-Port like functionality in a
similar fashion to the "upgradable" shared-Chan? I think multi-producer,
multi-consumer would be pretty swell as within reach defaults. I
understand, in previous runtime implementations, doing sendable Ports was
pretty much Out Of The Question. I'm curious if things have changed enough
to warrant revisiting to see if it's worth it? Do you think it's a bridge
too far?

I know this distracts from the current issue that your proposal is
addressing and I apologize for that. I'm just curious if it's worth
throwing into the mix.

As it currently stands, though, your proposal gets a +1 from me.


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/20140113/4fdf06af/attachment.html>

More information about the Rust-dev mailing list