On Tue, Dec 31, 2013 at 6:16 AM, Patrick Walton <pcwal...@mozilla.com>wrote:
> Can someone address Simon Marlow's point here? > > https://plus.google.com/109566665911385859313/posts/FAmNTExSLtz > > > unbuffered channels are "synchronous" in the sense that both reader > > and writer must be ready at the same time. It's easy to deadlock if > > you're not careful. Buffered channels allow asynchronous writes, but > > only up to the buffer size, so that doesn't actually make things > > easier. Fully asynchronous channels, like you get in Erlang and > > Haskell don't have this problem, but they are unbounded so you have > > to be careful about filling them up (Erlang uses a clever scheduling > > trick to mitigate that problem, though). > > I am concerned that we are only hearing one side of the argument here, and > Haskell folks seem to have come down fairly strongly in favor of unbounded > channels. > > It also seems to me that the argument is partial, and only consider blocking sends. It would be interesting to know if they envisaged non-blocking sends and if so why they seem to have been discarded. > To reiterate: At this point I believe we should have both as first-class > citizens, like `java.util.concurrent`. Choosing one or the other seems to > be neglecting too many use cases. > > > Patrick > > _______________________________________________ > Rust-dev mailing list > Rust-dev@mozilla.org > https://mail.mozilla.org/listinfo/rust-dev >
_______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
