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. 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. 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. Best Regards Matthias > > Supporting selection over multiple queues would involve using kqueue > > on FreeBSD/OSX and eventfd/epoll on Linux instead of a condition > > variable for the not empty condition. For Windows, the regular > > condition variables will work fine. This does have a cost, and may not > > make sense with the same type. > > > I believe the single-consumer restriction has to do with the complexity of > implementing 'select' with multiple consumers. Do you have that > implemented in rust-core? > > _______________________________________________ > 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
