Broadcast vs mpsc channels?
from SpiderUnderUrBed@lemmy.zip to rust@programming.dev on 11 May 11:21
https://lemmy.zip/post/38313505

Hello, I am starting to learn and play around with tokio and multithreaded code. I am now playing around with websockets, I don’t quite understand the difference between broadcast and mpsc, and when would you use either, I mean, I am assuming broadcast is intended for multiple clients, but multiple clients were able to connect to my mscp channel, and receive a bit of data (but it was weird and partial). So I don’t quite get it.

#rust

threaded - newest

taladar@sh.itjust.works on 11 May 11:27 next collapse

Broadcast sends every value to every consumer, mpsc only allows a single consumer to get each value.

SpiderUnderUrBed@lemmy.zip on 11 May 11:33 collapse

Weird thing is, is that. I only had one mscp in my app state, it was behind a arc mutex and code that accessed it was running asynchronously, but, somehow they all got the same messages for a bit, then like, stopped or got very partial messages except the intended recipient (they got the full message). Is this some memory issue, or race condition?

I don’t have this issue switching to broadcast but I’m confused

calcopiritus@lemmy.world on 11 May 12:02 next collapse

The problem might be the arc mutex. mpsc are already clone, send and sync. When you clone an arc mutex T, you are cloning the arc. But mpsc probably needs to be cloned itself to work properly.

jenesaisquoi@feddit.org on 12 May 08:00 collapse

You don’t need to arc-mutex an mpsc. On the sender side, clone the sender as many times as you need and pass it by value (each sender owns a clone). On the receiver side you must have only one (mpsc is multiple producer single consumer) which is owned by the receiver.

If you need multiple producers and multiple consumers I recommend this crate: crates.io/crates/async-channel

The same pattern applies. No arc, no mutex, just clone the sender and receiver handles for each producer and consumer respectively.

Don’t worry about the cloning, channels are specifically designed to be used this way.

TehPers@beehaw.org on 11 May 11:41 collapse

Tokio’s broadcast module is a mpmc messaging queue.

The terms “mpsc” and “mpmc” refer to how the channels can be used. Breaking down the letters, there are two sides to a channel:

  • p is producer, or transmitter/sender. This side sends data
  • c is consumer, or receiver/reader. This side receives data.

Data only flows one way through a channel. Each side may have a restriction on how many members can be on that side:

  • s is single, so this side cannot be cloned. You only have one object that can interact with this side (so only one sender or only one receiver)
  • m is multiple, so this side can be cloned. Any number of objects can exist that interact with this side (so a bunch of simultaneous senders or receivers)

A mpsc channel can only have one consumer, so only one thread can receive messages at a time, and it can only receive those messages once.

A mpmc channel can have many consumers, so multiple threads can receive messages at once, and a thread can receive a message multiple times (through multiple receivers).

Both can have multiple simultaneous producers.