Implement Sync for Sender + Receiver

[Dr-Emann]

I believe it's safe to make Sender Sync for Sender unconditionally, since none of its methods take &self. But I think even just unsafe impl <T: Sync> Sync for Sender/Receiver should be fine.

[faern]

I'm not sure this is actually correct (or wanted?). The library and code is written with the intention to be single producer and single consumer. Sync implies that one sender/receiver instance could be used concurrently by multiple threads. For Sender I don't know what benefits it yields to implement Sync. It has a single consuming method anyway, so a &Sender can't do anything. For Receiver I have not yet evaluated if calling for example recv_ref concurrently in two threads would be safe, but the code was not written with that in mind.

Can you elaborate on the use case for this, why you want the endpoints to be Sync?

[faern]

No, Receiver: Sync would not be a sound implementation. Consider the code path in start_recv_ref that first reads the channel state -> reads EMPTY -> channel.write_waker(ReceiverWaker::current_thread()). In this code path two threads could race to write their own ReceiverWaker to the same place in memory and then park. Both threads would then believe they are responsible for freeing the heap memory later when they wake up etc. It would not be correct in many ways.

[PPakalns]

For those that need Sync for these types. (Due to storing receiver, sender with other data that can be read)

You can add wrapper types for Receiver, Sender that allow only modification of inner content with &mut access that guarantees at most one possible access of inner data. (In other words, make all non mutable (unique) access not possible).

And add Sync implementation to these wrapper types.

[faern]

For those wanting this/is subscribed to this issue: Sync was implemented for the Sender in #55! Will be released soon. As stated above the Receiver can definitely not be Sync.