On Sat, Jan 25, 2014 at 6:44 AM, Lee Braiden <[email protected]> wrote: > On 25/01/14 10:48, Daniel Micay wrote: >> >> I doubt it's really any easier to avoid race conditions with channels as >> opposed to concurrent data structures, whether they are persistent or >> mutable. Keep in mind that Rust won't let you have data races whether or not >> you are sharing data. > > > With messages sent on channels, you're encoding a message-based protocol (by > definition) and something at least similar to state machines for each > receiver task. IF the compiler understands that, then you can, potentially, > add additional, strong, static checking, and much more helpful diagnostics.
You can say the exact same thing about other concurrent data structures. It's easy enough to expose a slow concurrent hash table API via message passing, so it's obviously no different... > You ARE sacrificing flexibility by working within that framework, but I > think the general idea is that most (all?) parallel jobs CAN be well > modelled by a message-passing protocol, and so the "extra flexibility" is > really just "ability to screw it up, without a framework". If you think > about it, this is really just encapsulation of concurrent data behind > accessor methods: the alternative is to randomly access shared data at any > time, which is clearly more risky (not JUST because of data races, but also > because of protocol violations / state-machine bugs), although it can > obviously be done equally well by hand, if you're very careful, and Rust's > data ownership will help, of course. It's no harder to screw up outside of message passing. You're not offering any valid points against concurrent data structures. > not JUST because of data races, but also because of protocol violations / > state-machine bugs Again, there is no risk of data races in Rust. There is also no increased risk in violating a protocol, as you can represent the same concepts with both and the compiler isn't going to be able to gain increased information from a queue used for message passing over a hash table. You could have support for building protocols that are provably free of data races, but there's no reason it has to be restricted to a FIFO queue and it will be unable to prove more when you're using the FIFO queue in an unrestricted fashion. > The main worry I have with message-passing/actor architectures is > performance, but that's exactly why the language should understand the > protocols and be able to compile a: send(b) b: receive(b); total += b down > to just total += b, if/when that's appropriate. These are never going to be language features and compiler magic like this simply isn't very realistic. It's quite ridiculous to talk about designing based on a fantasy world with a sufficiently smart compiler when you're talking about a language like Rust exposing the details of memory layout, ownership and lifetimes. _______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
