On Fri, Jan 24, 2014 at 3:33 PM, Tony Arcieri <[email protected]> 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. _______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
