[rust-dev] Why focus on single-consumer message passing?

Matthias Einwag matthias.einwag at googlemail.com
Fri Jan 24 12:03:23 PST 2014


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
> Rust-dev at mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev



More information about the Rust-dev mailing list