[rust-dev] Why focus on single-consumer message passing?
danielmicay at gmail.com
Sat Jan 25 00:50:26 PST 2014
On Fri, Jan 24, 2014 at 3:03 PM, Matthias Einwag
<matthias.einwag at googlemail.com> 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:
> 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.
More information about the Rust-dev