Is there any particular reason why Sender doesn't impl Sync?
I have a use case where I need this impl and it seems like Sender should trivially satisfy its definition so I'm wondering if I'm overlooking something.
The reason why I think it should be okay is because all of the Sender methods take self by-value, so &Sender<T>: Send (trivially) because you can't actually do anything with the Sender in that case, and &Sender<T>: Send implies Sender<T>: Sync.
As for the use case, I have an algorithm where I am using a DashMap<T, Option<Vec<oneshot::Sender<()>>>> to solve an ordering problem, where the map is used as a ledger to determine whether certain tasks have already completed, and to notify pending tasks when ready using the oneshot::Sender<()>.
The only way I can make this type-check (without rolling my own unsafe impl Sync wrapper) is if I wrap the channels in a Mutex like this: DashMap<T, Option<Vec<Mutex<oneshot::Sender<()>>>>>.
But this seems kind of pointless because I never use the Mutex for locking (in fact it's not possible because it doesn't return the channel by-value): instead I have to immediately consume the Mutex with .into_inner and then call send on the channels. So the Mutex is only used to satisfy the Sync requirement.
I suppose maybe the reason the Sync impl wasn't already added is because it seems useless/trivial, and indeed the constraint for use here with DashMap is a little misleading: The reason the algorithm I describe works is because I remove the entry from the map (by-value), not using a typical lookup (which wouldn't allow me to send on the channel).
So this is sort of a case of the the DashMap API being overly conservative, but in any case, if there's no reason why Sync is problematic, it would be useful to have.
I just noticed #26 (comment). The above at least provides a real-world use.
Is there any particular reason why
Senderdoesn't implSync?I have a use case where I need this impl and it seems like
Sendershould trivially satisfy its definition so I'm wondering if I'm overlooking something.The reason why I think it should be okay is because all of the
Sendermethods takeselfby-value, so&Sender<T>: Send(trivially) because you can't actually do anything with theSenderin that case, and&Sender<T>: SendimpliesSender<T>: Sync.As for the use case, I have an algorithm where I am using a
DashMap<T, Option<Vec<oneshot::Sender<()>>>>to solve an ordering problem, where the map is used as a ledger to determine whether certain tasks have already completed, and to notify pending tasks when ready using theoneshot::Sender<()>.The only way I can make this type-check (without rolling my own
unsafe impl Syncwrapper) is if I wrap the channels in aMutexlike this:DashMap<T, Option<Vec<Mutex<oneshot::Sender<()>>>>>.But this seems kind of pointless because I never use the
Mutexfor locking (in fact it's not possible because it doesn't return the channel by-value): instead I have to immediately consume theMutexwith.into_innerand then call send on the channels. So theMutexis only used to satisfy theSyncrequirement.I suppose maybe the reason the
Syncimpl wasn't already added is because it seems useless/trivial, and indeed the constraint for use here withDashMapis a little misleading: The reason the algorithm I describe works is because I remove the entry from the map (by-value), not using a typical lookup (which wouldn't allow me to send on the channel).So this is sort of a case of the the
DashMapAPI being overly conservative, but in any case, if there's no reason whySyncis problematic, it would be useful to have.I just noticed #26 (comment). The above at least provides a real-world use.