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.
alice
#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
I'm curious what you mean here -- are you expecting more available memory?
I mean if Receiver is Sync, there will be more user cases which Sync Receiver can fit in.Forgive me for poor engilish.
Thany you for your explanation! 
Ah, I see, yes that makes sense.