[rust-dev] Why focus on single-consumer message passing?
leebraid at gmail.com
Sat Jan 25 03:44:17 PST 2014
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
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.
More information about the Rust-dev