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

Jeremy Ong jeremycong at gmail.com
Sat Jan 25 02:37:26 PST 2014


> 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 <danielmicay at gmail.com>wrote:

> 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:
> > 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
> Rust-dev at mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20140125/f1fa6deb/attachment.html>


More information about the Rust-dev mailing list