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

Daniel Micay danielmicay at gmail.com
Sat Jan 25 00:37:25 PST 2014


On Fri, Jan 24, 2014 at 3:33 PM, Tony Arcieri <bascule at gmail.com> wrote:
>
> While I agree and I'm a fan of multi-consumer systems like Java
> ThreadPoolExecutor and Disruptor, I think as a general pattern (and not
> necessarily performance-oriented one), the actor model (which is many-to-one
> by design) is probably going to be the most useful to people.
>
> Just my 2c. I see actors as a generalized, higher-level pattern that can be
> built atop CSP, and one I would love to see support for (in the form of an
> Erlang/OTP-alike for Rust)

I don't think it's the place of the standard library of a systems
language to choose the concurrency model for users of the language.
It's a performance-oriented language and tasks are in the same weight
class as threads. There will be a need for task pools and task
graphs/trees layered on top for CPU-bound work.

If single consumer queues can offer a performance advantage over ones
without the restriction and are a common pattern, then they're worth
providing. However, I think the flexible implementation should be the
most prominent as you can express a problem naturally rather than
trying to fit it into an opinionated model. A more restricted queue is
then a drop-in replacement if it meets the needs of the code, but is
just an optimization.


More information about the Rust-dev mailing list