[rust-dev] Many-to-many channels

[Calder Coalson]

Hi,

First, thanks for all your hard work, and for such a wonderful language!
I'm quite new to Rust, but so far I've found it a real pleasure to work
(and think) in.

I did run into one small hitch with the standard library recently. I'm
writing some multithreaded code that lends itself naturally to a multiple
producer, multiple consumer model. I wanted to use std::comm's channels,
but found they only support many-to-one channels. So I have two questions
for the list:
1) Is there a trade off to offering many-to-many channels, or is it simply
that no one has requested it yet?
2) If the latter, how can I help?

Thanks!
-Calder
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20141004/a58b2857/attachment.html>

[Peter Marheine]

Is there a particular reason you need a Channel rather than some other
primitive? If not, sync::mpmc_bounded_queue will probably do what
you're looking for.

Hi,
First, thanks for all your hard work, and for such a wonderful language! I'm
quite new to Rust, but so far I've found it a real pleasure to work (and
think) in.
I did run into one small hitch with the standard library recently. I'm
writing some multithreaded code that lends itself naturally to a multiple
producer, multiple consumer model. I wanted to use std::comm's channels, but
found they only support many-to-one channels. So I have two questions for
1) Is there a trade off to offering many-to-many channels, or is it simply
that no one has requested it yet?
2) If the latter, how can I help?
Thanks!
-Calder
_______________________________________________
Rust-dev mailing list
Rust-dev at mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

[Calder Coalson]

That's exactly what I was looking for, thanks!

Out of curiosity, why are Rust channels built on top of MPSC queues rather
than MPMC queues?

Post by Peter Marheine
Is there a particular reason you need a Channel rather than some other
primitive? If not, sync::mpmc_bounded_queue will probably do what
you're looking for.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20141004/2b6f0753/attachment.html>

[Calder Coalson]

On closer inspection, mpmc_bounded_queues aren't quite what I want. I want
consumers to block if the queue is empty rather than returning None.

On Sat, Oct 4, 2014 at 12:21 PM, Calder Coalson <caldercoalson at gmail.com>

Post by Calder Coalson
That's exactly what I was looking for, thanks!
Out of curiosity, why are Rust channels built on top of MPSC queues rather
than MPMC queues?

Post by Peter Marheine
Is there a particular reason you need a Channel rather than some other
primitive? If not, sync::mpmc_bounded_queue will probably do what
you're looking for.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20141004/434c77ee/attachment.html>

[Evan G]

Couldn't you just implement that with a loop and a match statement?

On Sat, Oct 4, 2014 at 4:25 PM, Calder Coalson <caldercoalson at gmail.com>

Post by Calder Coalson
On closer inspection, mpmc_bounded_queues aren't quite what I want. I
want consumers to block if the queue is empty rather than returning None.
On Sat, Oct 4, 2014 at 12:21 PM, Calder Coalson <caldercoalson at gmail.com>

Post by Calder Coalson
That's exactly what I was looking for, thanks!
Out of curiosity, why are Rust channels built on top of MPSC queues
rather than MPMC queues?

Post by Peter Marheine
Is there a particular reason you need a Channel rather than some other
primitive? If not, sync::mpmc_bounded_queue will probably do what
you're looking for.

_______________________________________________
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/20141004/6571df5a/attachment.html>

[Sean McArthur]

Post by Evan G
Couldn't you just implement that with a loop and a match statement?

Wouldn't that just make the process burn cpu, instead of being able to
allow other threads to work?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20141004/4c30cd49/attachment.html>

[Zaven Muradyan]

Post by Sean McArthur
Wouldn't that just make the process burn cpu, instead of being able to
allow other threads to work?

I would think so, yes. From what I can tell, `std::comm` channels do
blocking by using `std::task::deschedule`, along with some internal
housekeeping that seems to be trying to avoid the situation whereby a
woken task tries to grab some data that has already been `recv()`'d by
someone else (although, I'm not sure how that would ever happen in a
SPSC scenario).

[Evan G]

Ahh that makes sense. Thanks both of you. I had an inkling that it was more
complicated then I thought, but I wasn't sure.

Post by Zaven Muradyan

Post by Sean McArthur
Wouldn't that just make the process burn cpu, instead of being able to
allow other threads to work?

I would think so, yes. From what I can tell, `std::comm` channels do
blocking by using `std::task::deschedule`, along with some internal
housekeeping that seems to be trying to avoid the situation whereby a woken
task tries to grab some data that has already been `recv()`'d by someone
else (although, I'm not sure how that would ever happen in a SPSC scenario).
_______________________________________________
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/20141004/7c807011/attachment.html>

[Calder Coalson]

What Sean said.

Post by Sean McArthur

Post by Evan G
Couldn't you just implement that with a loop and a match statement?

Wouldn't that just make the process burn cpu, instead of being able to
allow other threads to work?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20141004/3217c180/attachment.html>