Why std's Receiver is not Sync, but tokio/futures's Receiver is Sync?

community
#1

Hi, everyone! I found the following phenomenon:

  • Sender in std::sync::mpsc is Send and not Sync.
  • SyncSender in std::sync::mpsc is Send and Sync.
  • Receiver in std::sync::mpsc is Send and not Sync.

However,in futures and tokio, all kinds of Sender and Receiver is Send and Sync.

I thought that if Receiver is Sync, it will have more space to use. So, what's the story or design consideration under this phenomenon? I am courious.

#2

Basically, it has to do with how they prevent you from having multiple receivers. (mpsc means multi-producer single-consumer)

For the std channel, the recv method takes &self but the type is not Sync so you can't call recv in parallel.

For the Tokio channel, the recv method takes &mut self, so even though the type is Sync, you can't call recv in parallel.

To be clear, I believe it is considered an API mistake to go with &self and !Sync for the std channel, and that &mut self is the better route.

5 Likes
#3

I'm curious what you mean here -- are you expecting more available memory?

#4

I mean if Receiver is Sync, there will be more user cases which Sync Receiver can fit in.Forgive me for poor engilish.

#5

Thany you for your explanation! :grinning:

#6

Ah, I see, yes that makes sense.

#7

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.