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
