> Rust should be providing the building blocks for a concurrency pattern > determined by the needs of the application. I don't think it should > push a specific design, as there are many ways of doing this with > their own merits.
There is a spectrum of flexibility and safety. I'll be honest, if given a 10000 LOC highly concurrent application to work with, I'd feel much more comfortable if things were primarily shared nothing and it was hard to abuse error-prone shared memory issues (race conditions, deadlock, etc). Those problems are even possible in CSP systems but at least they're easier to identify and eliminate. It could be argued that if all you want are primitive build blocks in a systems language, it already exists in C. As an aside, I like the distinction in Haskell between threads (parallelism units mapped to cores) and par/pseqs (green concurrency units). Rust tasks feel more like a library feature to me rather than a systems feature. Perhaps a much more flexible systems-oriented threaded model is better suited for a primitive more analogous to the pthread? On Sat, Jan 25, 2014 at 12:50 AM, Daniel Micay <[email protected]>wrote: > On Fri, Jan 24, 2014 at 3:03 PM, Matthias Einwag > <[email protected]> wrote: > > Hi everyone, > > > > multi-consumer has many faces. > > Should this send a copy to each consumer? If yes than you can probably > do > > this easier by creating N SPSP channels. > > > > Or thus that mean you send 1 element and the first task that catches it > > wins. That's the classical thing for work queues. You put something into > a > > single work queue which is accessed by multiple threads and the first one > > that reads it performs the work. > > Yes, I mean a work queue style of channel. > > > You don't need a select thing for multiple consumers. You can also wakeup > > one or all possible consumers with a condition variable or the other > > proposed mechanisms. > > However I doubt that such a channel is useful for the majority of > people, if > > they don't want to implement their own threading and scheduling stuff. > > I didn't state otherwise. It's a side note at the bottom about an > optional feature for that reason. > > > You need a select/WaitForMultipleObjects/etc. mechanism only when you > want > > to monitor multiple channels in parallel by a single task. > > I already implemented that as one can see here: > > https://github.com/mozilla/rust/issues/11165#issuecomment-32798282 > > I used eventfd there and in the meanwhile also made some benchmarks about > > the overhead of eventfd vs. notification with a condition variable. It's > > actually not that much. > > But the question there is more how you would your APIs and the Task > system > > to look like. > > Rust should be providing the building blocks for a concurrency pattern > determined by the needs of the application. I don't think it should > push a specific design, as there are many ways of doing this with > their own merits. > _______________________________________________ > Rust-dev mailing list > [email protected] > https://mail.mozilla.org/listinfo/rust-dev >
_______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
