On 12/24/13 5:45 PM, Daniel Micay wrote:
Bounded channels present the choice between blocking (with an optional
timeout) when the channel is full or making a non-blocking call with
custom handling of the error case.
I prefer the latter.
Unbounded channels don't provide a
way to write robust systems without layering on application-level
message passing and book-keeping. It doesn't absolve you of handling
deadlocks by considering the bounds because you're just going to get a
far worse out-of-memory condition instead.
I don't think OOM is far worse than a deadlock. On the server side both
amount to "get a page and log into the machine and restart the affected
process". Which is of course very bad, but I don't think one is that
much worse than the other.
Anyway, I'm OK with bounded channels to avoid OOM, but I'm pretty unsure
about the following three things:
1. Blocking on the sender side when the queue is full. This causes
deadlocks. You can create the equivalent using two channels if you
really want this behavior.
2. Allocating a flat array with the size of the bound up front for
channels. In a producer/consumer scenario, you want the bound to be high
to maximize parallelism, without paying a constant memory usage penalty.
3. Having a bound of 1 by default. The default should allow for parallelism.
Haskell may be a nice thing to look at here: the unbounded channel is
the primitive, and bounded channels are built on top of unbounded ones
using an `MVar` to rate limit. Such a thing could be easily built in
Rust using a channel paired with an `AtomicUint`.
Patrick
_______________________________________________
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
