

Concurrency Models, Rust, and Servo - bjz_
http://www.lars.com/concurrency/rust/servo/2013/12/21/concurrency-rust-and-servo.html

======
bjz_
For some context, the 80+ message discussion that was mentioned in the first
paragraph stem from this post: [https://mail.mozilla.org/pipermail/rust-
dev/2013-December/00...](https://mail.mozilla.org/pipermail/rust-
dev/2013-December/007414.html)

Lars works for Mozilla on the Servo team, but has done work on the CML [1] and
Manticore [2] languages, mainly in the realm of performance optimization I
believe.

[1] [http://cml.cs.uchicago.edu/](http://cml.cs.uchicago.edu/)

[2] [http://manticore.cs.uchicago.edu/](http://manticore.cs.uchicago.edu/)

~~~
larsberg
As bjz points out, my background is from CML, so my experience has biased me a
bit towards synchronous send for same machine/process programming models and
async for distributed models. But I tried to give them both a fair shake in
the context of, "What implementation strategy makes Servo fast and reliable?"

------
brson
Awesome post. All this discussion makes me realize that we haven't hit the
sweet spot yet and need to keep considering more message passing use cases. I
am wary though of providing too many options and very much want to have one
channel type that is most useful and least error prone that we can recommend
by default.

I do disagree slightly with the final conclusion that context switch on send
defeats the advantage of unbounded channels since work stealing will ensure
the sender runs again very soon.

------
noelwelsh
It's good to read an intelligent discussion of the pros and cons of
synchronous and asynchronous message passing. Asynchronous is more general,
but building protocols on top of it can be a real pain (i.e. implementing ACKs
and so on).

Gotta say, everything I read about Rust makes me like it more.

