[rust-dev] Why focus on single-consumer message passing?

Lee Braiden 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 
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.


More information about the Rust-dev mailing list