Replace use of crossbeam_channel with std::sync::mpsc

[james7132]

What problem does this solve or what need does it fill?

In Rust 1.67, a vendored implementation of crossbeam_channel will be used to back std::sync::mpsc. This was added in rust-lang/rust#93563.

What solution would you like?

When 1.67 lands, use std::sync::mpsc instead of crossbeam_channel in single-producer/single-consumer and multiple-producer/single-consumer use cases, after bumping the MSRV. Potentially shrink the dependency tree.

What alternative(s) have you considered?

Continue using crossbeam_channel as is.

[alice-i-cecile]

This will be unblocked on January 26th, 2023. At that point, this should be straightforward to tackle.

If you want to start on a PR before then, prepare it by swapping your compiler version to nightly.

[harudagondi]

I think it should be beta, not nightly.

[OneFourth]

Hi, I wanted to try this as a first issue but I think there might be a problem. As mentioned here

bevy/examples/async_tasks/external_source_external_thread.rs

Line 4 in d4babaf

// Using crossbeam_channel instead of std as std `Receiver` is `!Sync`

Since Resource requires Sync there's a few errors when building bevy_asset and bevy_time (such as std::sync::mpsc::Receiver<Instant> cannot be shared between threads safely). Sorry, I don't understand Send and Sync all too well, so I'm not sure if there's a proper workaround or if this is just fundamentally incompatible with the std implementation.

[james7132]

Ah the good ol' problem of !Sync components and resources. Sync requires that &T be safe to send to another thread, but that says nothing about &mut T, which is always safe to send to another thread provided the type is Send, which the receiver is . You could try using bevy_utils::sync_cell::SyncCell to wrap the reciever, which will make it Sync but only allow you to get a mutable borrow to read it, which I think should be fine for both bevy_asset and bevy_time.

[OneFourth]

So I bit off more than I can chew and gave this a try anyway, bevy_asset in particular is a rabbit hole of build errors trying to get it to work, the other crates should be ok I think.

Can I open a pull request for what I've got so far? I've still got some compile errors that I can't figure out. Or should I just give up on trying to do this one?

[alice-i-cecile]

@OneFourth A draft PR would be super useful, even if you immediately close it :) Link this issue from there so others can see what you've got.

[james7132]

As mentioned in #7346, this seems impossible or generally undesirable with the current stable interface of std::sync::mpsc. Closing.