<div dir="ltr"><div>This is a great proposal, Brian.<br><br>I have no criticisms of the proposal itself, feeling that it's a level-headed response to the previous threads on this issue.<br><br>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?<br>
<br>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.<br><br></div><div>As it currently stands, though, your proposal gets a +1 from me.<br>
<br></div>Cheers</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Jan 13, 2014 at 6:48 PM, Brian Anderson <span dir="ltr"><<a href="mailto:banderson@mozilla.com" target="_blank">banderson@mozilla.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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:<br>


<br>
* Running out of memory is an awful failure mode for debugging.<br>
* Choosing an appropriate bounded queue size is hard.<br>
* Dealing with backpressure is hard.<br>
* Most channels are not filled without bound.<br>
<br>
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.<br>


<br>
# Changes to `Chan`<br>
<br>
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.<br>


<br>
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`.<br>


<br>
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.<br>


<br>
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 ...<br>


<br>
# Synchronous and bounded channels<br>
<br>
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.<br>


<br>
Comments?<br>
<br>
Regards,<br>
Brian<br>
______________________________<u></u>_________________<br>
Rust-dev mailing list<br>
<a href="mailto:Rust-dev@mozilla.org" target="_blank">Rust-dev@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/rust-dev" target="_blank">https://mail.mozilla.org/<u></u>listinfo/rust-dev</a><br>
</blockquote></div><br></div>