Weird issue about ring-channel HOT 2 CLOSED

Another workaround: if channel is cloned before and then passed by value, it compiles fine.
So this code compiles:

    let tx2 = tx.clone();
    tst_nested(tx2).await;

While this one doesn't:

    tst_nested(tx.clone()).await;

Looks like a compiler bug now (?) I checked on beta and last nightly.

from ring-channel.

Thanks for taking the time to report this.

TL;DR;

This is neither an issue with the compiler, nor with ring_channel.

Why?

To understand why, consider the reduced snippet below, which reproduces the same error you see on 1.40.0-nightly (3a9abe3f0 2019-10-15).

async fn second(_: RingSender<u32>) {}

async fn first(tx: RingSender<u32>) {
    second(tx.clone()).await;
}

let mut pool = ThreadPool::new().unwrap();
let (tx, _) = ring_channel(std::num::NonZeroUsize::new(1).unwrap());
pool.spawn(first(tx)).unwrap();

Let us rewrite the line second(tx.clone()).await; the way the compiler sees it:

async {
    let tx2 = tx.clone();
    second(tx2).await
}.await

Notice that tx is captured by reference, since its only use within the async block binds it to a shared reference in the call to clone. Recall that the async block is scheduled for execution in the ThreadPool and the corresponding task can be picked up by any thread, so &tx is required to implement Send, or equivalently, tx is required to implement Sync, which it does not, hence the compilation error.

Why does removing the call to clone avoid the error?

This is what the compiler sees in this case:

async {
    second(tx).await
}.await

Notice that tx is captured by value, since its only use within the async block binds it to a move into second. Following the same reasoning around the fact the async block can be executed on any thread, we conclude that tx is only required to implement Send, which it does, so the borrow checker is happy.

Why does cloning tx upfront work?

Once again, let's rewrite it the way the compiler sees it:

let tx2 = tx.clone();
async {
    second(tx2).await
}.await

Following the same logic, tx2 is captured by value, which we have just verified to be fine.

Why does crossbeam_channel work when captured by reference?

Simply because crossbeam_channel::Sender does implement Sync.

Why doesn't ring_channel::Sender implement Sync?

The way it's currently implemented does allow it to implement Sync, but I decided to reserve the right to change the implementation in the future in a way that breaks this property, considering it can just be cloned instead .

from ring-channel.