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 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.
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.
-- Lee _______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
