Merge crossbeam-channel into `std::sync::mpsc` #93563

ibraheemdev · 2022-02-01T22:26:20Z

This PR copies the crossbeam-channel crate into the standard library as a private module, sync::mpmc. sync::mpsc is now implemented as a thin wrapper around sync::mpmc. The primary purpose of this PR is to resolve #39364, so there are no public API changes.

The reason #39364 has not been fixed in over 5 years is that the current channel is incredibly complex. It was written many years ago and has sat mostly untouched since. crossbeam-channel has become the most popular alternative on crates.io, amassing over 30 million downloads. While crossbeam's channel is also complex, like all fast concurrent data structures, it avoids some of the major issues with the current implementation around dynamic flavor upgrades. The new implementation decides on the datastructure to be used when the channel is created, and the channel retains that structure until it is dropped.

Replacing sync::mpsc with a simpler, less performant implementation has been discussed as an alternative. However, Rust touts itself as enabling fearless concurrency, and having the standard library feature a subpar implementation of a core concurrency primitive doesn't feel right. The argument is that slower is better than broken, but this PR shows that we can do better.

As mentioned before, the primary purpose of this PR is to fix #39364, and so the public API intentionally remains the same. After that problem is fixed, the fact that sync::mpmc now exists makes it easier to fix a limitation of mpsc, the fact that it only supports a single consumer. spmc and mpmc are two other common concurrency patterns, and this change enables a path to deprecating mpsc and exposing a general sync::channel module that supports multiple consumers. It also implements other useful methods such as send_timeout. That said, exposing MPMC and other new functionality is mostly out of scope for this PR and it would be helpful if discussion stays on topic :)

For what it's worth, the new implementation has also been shown to be more performant in some basic benchmarks.

cc @taiki-e

r? rust-lang/libs

joshtriplett · 2022-02-01T22:54:31Z

Thanks for working on this!

I'd like to avoid adding any new public API (like mpmc) in the course of fixing mpsc, even if it's unstable. Let's focus on making mpsc less broken.

Also, the phrasing of the PR seems unfortunate; crossbeam channel has lots of users, but that doesn't make it "the defacto replacement".

ibraheemdev · 2022-02-01T22:59:24Z

I'd like to avoid adding any new public API (like mpmc) in the course of fixing mpsc, even if it's unstable. Let's focus on making mpsc less broken.

sync::mpmc is private. Avoiding any public API changes is an explicit goal of this PR.

Also, the phrasing of the PR seems unfortunate; crossbeam channel has lots of users, but that doesn't make it "the defacto replacement".

True, I just meant to say it is the most popular replacement. I'll update the description.

jyn514 · 2022-02-02T17:29:18Z

This PR imports the crossbeam-channel crate into the standard library as a private module, sync::mpmc.

Rather than copying the whole crate, you can add it as an internal dependency and re-export it; that will make it easier to update in the future. See hashbrown in library/std/src/collections/hash/map.rs for an example.

ibraheemdev · 2022-02-02T17:45:41Z

@jyn514 The problem with that is crossbeam-channel depends on crossbeam-utils, which depends on lazy_static and includes many utilities that we doesn't need. sync::mpmc doesn't contain the entire crate, only the parts necessary to bounded, unbounded, and rendezvous channels. This could work if a crossbeam-channel-core crate some feature flags is created that we depend on, but we discussed this before and would like to see if the libs team is generally in support of this change before worrying about integration details.

bjorn3 · 2022-02-02T17:47:46Z

Crossbeam-channel also directly depends on libstd for getting the current thread id: https://github.com/crossbeam-rs/crossbeam/blob/85d0bdc95cdac6450ac1ba4ed587f362a5235e60/crossbeam-channel/src/waker.rs#L274 It probably also depends on other parts of libstd to wake up the right thread.

the8472 · 2022-02-02T20:51:47Z

There is a UI test (src/test/ui/threads-sendsync/mpsc_stress.rs) that is partially disabled. This PR should enable it. And make sure that it still detects the bug (red-green).

SimonSapin · 2022-02-03T12:05:58Z

sync::mpmc contains a couple thousands lines of code and is effectively of fork of (part of) crossbeam-channel. What is the plan for both of their maintenance? Should bug fixes in one be manually ported to the other? Or is the intent that some plan will be made at a later date to go back to a single "source of truth" in terms of source code repositories?

If the latter, would it make sense for rust-lang/rust to be the source of truth for some pieces of code that are both used in the standard library (but not exposed, so no API stability requirement) and separately published to crates.io (where semver-breaking version numbers can be used as needed) ?

This could be a way to resolve the conflict between: the std crate wants to use something from crates.io, but that crate needs API (like thread IDs) that’s only exposed publicly by std.

thomcc

I'm surprised this code does as much dubious spinning as it does. In practice most of it you'd expect not to hurt that badly (which matches my experience with crossbeam), but on some arches a few of the placements of backoff.spin() could have bad behavior.

The spinlock was a surprise though. I had no idea crossbeam had one.

thomcc · 2022-02-04T01:46:41Z

library/std/src/sync/mpmc/utils.rs

+    }
+}
+
+const SPIN_LIMIT: u32 = 6;


1 << 6 calls to hint::spin_loop() is... very aggressive. Those calls tend to be a few hundred cycles. Actually, it's 1 << 6 1 << 5 1 << 4 ... before it falls back to pinging thread::yield(), which is not really ideal either — "switch to random thread" is almost always bad behavior in real code.

Changed the code to use quadratic instead of exponential backoff (437ea34). The fallback to thread::yield is only in blocking loops, where there isn't really any other option..

thomcc · 2022-02-04T02:52:03Z

library/std/src/sync/mpmc/array.rs

+                    }
+                    Err(h) => {
+                        head = h;
+                        backoff.spin();


It's an antipattern to spin in the failure case of a compare_exchange_weak loop like this (there are a few others too in this code). For those you should just update the start var and continue to retry immediately. There are a lot of reasons doing it the way you have is bad:

The code just got an updated head value right before waiting. The best time to use it was right after getting the updated value, not later. Waiting will increase the likelihood that that value becomes stale, especially as the spin count gets higher.

If you look at the asm on arm, you can see that in these cases it could easly just repeatedly end up repeatedly doing ldrex, bailing out and clrex spinning, without ever getting to even try the strex https://rust.godbolt.org/z/aYYEKd6rE

You're basically not allowed to do anything complex inside the ll/sc loop so in practice calling the backoff here makes the code much worse as it doubles-up the loop to manage this.

The compare_exchange was weak so it may have a totally spurious failure anyway.

Not an issue here, but it can cause livelock if you're unlucky and the backoff count and atomic are on the same line.

In practice most people should use AtomicFoo::fetch_update for this stuff which gets all of this right, and is less tedious, and expresses intent better too. That said, this loop does enough that it might be hard to make that way.

The other usage function might be okay -- or, I don't love it (it seems like it would just make things worse here... is there a specific situation that was trying to be avoided), but this one is wrong.

(I will note that the implementations that are cited as reference don't have it, and it's surprising to see something like this, since I think it doesn't actually have to wait for other threads to make progress...)

As an aside, this is great advice and something I haven't seen very well documented anywhere. Any chance you'd consider writing this up as a blog post, or better yet, find a way to add it to the std docs?

There is actually a good reason for spinning on CAS failure: if a thread encounters a lot of CAS failures then it means that the atomic it is trying to access is heavily contended. In such a situation where multiple threads are trying to access the same cacheline, you can significantly improve throughput by backing off and letting a single thread access the atomic at a time.

Essentially the access patterns go from:

Thread A Thread B Thread A Thread B Thread A Thread B Thread A Thread B

to:

Thread A Thread A Thread A Thread A Thread B Thread B Thread B Thread B

This improves throughput since the cacheline stays on the same CPU across multiple accesses.

This optimization looks good in benchmarks (I do something similar in parking_lot) but it is unclear how much impact it has on real world programs. I don't even know where to begin measuring this.

Updated the code to reload the head after spinning to reduce the likelihood of it being stale (0ae5d53).

thomcc · 2022-02-04T03:20:29Z

library/std/src/sync/mpmc/utils.rs

+const YIELD_LIMIT: u32 = 10;
+
+/// Performs exponential backoff in spin loops.
+pub struct Backoff {


If we keep this code in the tree, please indicate that this shouldn't be used or emulated elsewhere in libstd?

thomcc · 2022-02-04T03:26:06Z

library/std/src/sync/mpmc/list.rs

+    /// Waits until a message is written into the slot.
+    fn wait_write(&self) {
+        let backoff = Backoff::new();
+        while self.state.load(Ordering::Acquire) & WRITE == 0 {


This was deeeply concerning at first, but in practice I think you'd expect this to only very rarely need to go into the loop given where it's called? Still...

thomcc · 2022-02-04T03:28:37Z

library/std/src/sync/mpmc/list.rs

+                Err(h) => {
+                    head = h;
+                    block = self.head.block.load(Ordering::Acquire);
+                    backoff.spin();


Same thing i said about spinning in compare_exchange_weak applies here.

Same fix as above.

library/std/src/sync/mpmc/utils.rs

thomcc · 2022-02-04T04:18:15Z

All that said, this code is vastly easier for me to follow than std::sync::mpsc — most of my complaints are relatively minor or easily fixed problems.

m-ou-se · 2022-02-16T16:41:03Z

This PR was briefly discussed in the library API meeting last week. We didn't reach any conclusion about future API changes like deprecation or adding an mpmc channel. That can be discussed separately if someone wants to put in the time and energy. We see this PR itself basically as a bugfix, requiring no FCP. A crater run might be useful though, and it's probably good if there's more than one reviewer. (Thanks @thomcc for helping out with reviewing!)

saethlin · 2022-02-16T23:09:44Z

@ibraheemdev You're asking people for review on the community Discord; I'm not really qualified to review this but I can offer some feedback.

In internal codebases, we make extensive use of crossbeam channels to communicate between well-named threads. This has the nice benefit that you can run top -H -p PID to get a very quick and very dirty visualization of what's taking up time in a running system. The downside is that crossbeam spins a lot, so certain components spend most of their time on CPU according to top spinning for messages. And therefore, the codebases are littered with this pattern:

loop {
    match rx.try_recv() {
        Ok(msg) => process(msg),
        Err(TryRecvError::Empty) => sleep(std::time::Duration::from_millis(1)),
        Err(TryRecvError::Disconnected) => break,        
    }
}

I've seen this pattern drop the top-reported CPU usage of a thread from 20% to 5%. But it is not at all clear whether this is beneficial for the behavior of the application. I can certainly imagine how this would result in throughput bubbles as objects accumulate in the channel over the course of the sleep.

I'm concerned that putting a spinny channel implementation that does awesome on bechmarks into std where it will hopefully be used by a lot of beginners and may cause said beginners to mis-assess the resource utilization/requirements of their code. "I upgraded to Rust 1.61 and my CPU usage doubled" is not a Reddit post I want to see. Perhaps even worse would be comments suggesting this sleep-on-empty pattern.

saethlin · 2022-02-17T01:24:35Z

I was asked for a reproducer of the above. I thought this would be hard but... it's not? Here's a ~25x reduction in CPU usage from the sleepy pattern over crossbeam defaults:
EDIT: Also included times for current std::sync::mpsc, the pattern has a similar effect but it seems std::sync::mpsc is both less spinny and more CPU intensive for the sleepy pattern.

fn main() {
    let (tx, rx) = crossbeam_channel::unbounded();
    for _ in 0..100 {
        std::thread::Builder::new()
            .name("worker".to_string())
            .spawn({
                let tx = tx.clone();
                move || {
                    for i in 0..usize::MAX {
                        tx.send(i).unwrap();
                        std::thread::sleep(std::time::Duration::from_millis(1));
                    }
                }
            })
            .unwrap();
    }

    let mut sum = 0usize;

    // This impl uses ~26% of a core in top for crossbeam
    // and ~11% of a thread for std::sync::mpsc
    for v in rx.iter() {
        sum = sum.wrapping_add(v);
    }

    // This impl uses ~0.9% of a core in top for crossbeam
    // and ~1.8% in current std::sync::mpsc
    /*
    loop {
        match rx.try_recv() {
            Ok(v) => {
                sum = sum.wrapping_add(v);
            }
            Err(crossbeam_channel::TryRecvError::Empty) => {
                std::thread::sleep(std::time::Duration::from_millis(1));
            }
            Err(crossbeam_channel::TryRecvError::Disconnected) => {
                break;
            }
        }
    }
    */

    println!("{}", sum);
}

kpreid · 2022-02-17T02:27:25Z

I'm concerned that putting a spinny channel implementation that does awesome on bechmarks into std where it will hopefully be used by a lot of beginners and may cause said beginners to mis-assess the resource utilization/requirements of their code. "I upgraded to Rust 1.61 and my CPU usage doubled" is not a Reddit post I want to see. Perhaps even worse would be comments suggesting this sleep-on-empty pattern.

Any applications which are more concerned with energy usage than throughput (which could include something as non-specialized as Rust in WASM in a web page that happens to be opened on a smartphone, as well as embedded applications) would correctly prefer to sleep rather than spin. This seems like an area where std should not be choosing the other option — users looking for high throughput can easily benchmark wall-time and choose to use a different implementation, but energy usage is harder to measure, and more often overlooked.

(Disclaimer: I'm not an expert in optimizing for either of the above; I've just heard a few things, and am trying to make sure this consideration isn't entirely overlooked.)

m-ou-se · 2022-02-17T08:46:02Z

Assigning @Amanieu and myself to review this, since we're both used to working with concurrency/atomics.

bors · 2022-03-11T02:06:32Z

☔ The latest upstream changes (presumably #94824) made this pull request unmergeable. Please resolve the merge conflicts.

…tch-implementation, r=compiler-errors Fix backoff doc to match implementation The commit 8dddb22 in the crossbeam-channel PR (rust-lang#93563) changed the backoff strategy to be quadratic instead of exponential. This updates the doc to prevent confusion.

Merge crossbeam-channel into `std::sync::mpsc` This PR imports the [`crossbeam-channel`](https://github.com/crossbeam-rs/crossbeam/tree/master/crossbeam-channel#crossbeam-channel) crate into the standard library as a private module, `sync::mpmc`. `sync::mpsc` is now implemented as a thin wrapper around `sync::mpmc`. The primary purpose of this PR is to resolve rust-lang#39364. The public API intentionally remains the same. The reason rust-lang#39364 has not been fixed in over 5 years is that the current channel is *incredibly* complex. It was written many years ago and has sat mostly untouched since. `crossbeam-channel` has become the most popular alternative on crates.io, amassing over 30 million downloads. While crossbeam's channel is also complex, like all fast concurrent data structures, it avoids some of the major issues with the current implementation around dynamic flavor upgrades. The new implementation decides on the datastructure to be used when the channel is created, and the channel retains that structure until it is dropped. Replacing `sync::mpsc` with a simpler, less performant implementation has been discussed as an alternative. However, Rust touts itself as enabling *fearless concurrency*, and having the standard library feature a subpar implementation of a core concurrency primitive doesn't feel right. The argument is that slower is better than broken, but this PR shows that we can do better. As mentioned before, the primary purpose of this PR is to fix rust-lang#39364, and so the public API intentionally remains the same. *After* that problem is fixed, the fact that `sync::mpmc` now exists makes it easier to fix the primary limitation of `mpsc`, the fact that it only supports a single consumer. spmc and mpmc are two other common concurrency patterns, and this change enables a path to deprecating `mpsc` and exposing a general `sync::channel` module that supports multiple consumers. It also implements other useful methods such as `send_timeout`. That said, exposing MPMC and other new functionality is mostly out of scope for this PR, and it would be helpful if discussion stays on topic :) For what it's worth, the new implementation has also been shown to be more performant in [some basic benchmarks](https://github.com/crossbeam-rs/crossbeam/tree/master/crossbeam-channel/benchmarks#results). cc `@taiki-e` r? rust-lang/libs

Pkgsrc changes: * Adjust patches and cargo checksums to new versions, but also one strange "mips" conditional. Upstream changes: Version 1.67.0 (2023-01-26) ========================== Language -------- - [Make `Sized` predicates coinductive, allowing cycles.] (rust-lang/rust#100386) - [`#[must_use]` annotations on `async fn` also affect the `Future::Output`.] (rust-lang/rust#100633) - [Elaborate supertrait obligations when deducing closure signatures.] (rust-lang/rust#101834) - [Invalid literals are no longer an error under `cfg(FALSE)`.] (rust-lang/rust#102944) - [Unreserve braced enum variants in value namespace.] (rust-lang/rust#103578) Compiler -------- - [Enable varargs support for calling conventions other than `C` or `cdecl`.] (rust-lang/rust#97971) - [Add new MIR constant propagation based on dataflow analysis.] (rust-lang/rust#101168) - [Optimize field ordering by grouping m\*2^n-sized fields with equivalently aligned ones.] (rust-lang/rust#102750) - [Stabilize native library modifier `verbatim`.] (rust-lang/rust#104360) Added and removed targets: - [Add a tier 3 target for PowerPC on AIX] (rust-lang/rust#102293), `powerpc64-ibm-aix`. - [Add a tier 3 target for the Sony PlayStation 1] (rust-lang/rust#102689), `mipsel-sony-psx`. - [Add tier 3 `no_std` targets for the QNX Neutrino RTOS] (rust-lang/rust#102701), `aarch64-unknown-nto-qnx710` and `x86_64-pc-nto-qnx710`. - [Remove tier 3 `linuxkernel` targets] (rust-lang/rust#104015) (not used by the actual kernel). Refer to Rust's [platform support page][platform-support-doc] for more information on Rust's tiered platform support. Libraries --------- - [Merge `crossbeam-channel` into `std::sync::mpsc`.] (rust-lang/rust#93563) - [Fix inconsistent rounding of 0.5 when formatted to 0 decimal places.] (rust-lang/rust#102935) - [Derive `Eq` and `Hash` for `ControlFlow`.] (rust-lang/rust#103084) - [Don't build `compiler_builtins` with `-C panic=abort`.] (rust-lang/rust#103786) Stabilized APIs --------------- - [`{integer}::checked_ilog`] (https://doc.rust-lang.org/stable/std/primitive.i32.html#method.checked_ilog) - [`{integer}::checked_ilog2`] (https://doc.rust-lang.org/stable/std/primitive.i32.html#method.checked_ilog2) - [`{integer}::checked_ilog10`] (https://doc.rust-lang.org/stable/std/primitive.i32.html#method.checked_ilog10) - [`{integer}::ilog`] (https://doc.rust-lang.org/stable/std/primitive.i32.html#method.ilog) - [`{integer}::ilog2`] (https://doc.rust-lang.org/stable/std/primitive.i32.html#method.ilog2) - [`{integer}::ilog10`] (https://doc.rust-lang.org/stable/std/primitive.i32.html#method.ilog10) - [`NonZeroU*::ilog2`] (https://doc.rust-lang.org/stable/std/num/struct.NonZeroU32.html#method.ilog2) - [`NonZeroU*::ilog10`] (https://doc.rust-lang.org/stable/std/num/struct.NonZeroU32.html#method.ilog10) - [`NonZero*::BITS`] (https://doc.rust-lang.org/stable/std/num/struct.NonZeroU32.html#associatedconstant.BITS) These APIs are now stable in const contexts: - [`char::from_u32`] (https://doc.rust-lang.org/stable/std/primitive.char.html#method.from_u32) - [`char::from_digit`] (https://doc.rust-lang.org/stable/std/primitive.char.html#method.from_digit) - [`char::to_digit`] (https://doc.rust-lang.org/stable/std/primitive.char.html#method.to_digit) - [`core::char::from_u32`] (https://doc.rust-lang.org/stable/core/char/fn.from_u32.html) - [`core::char::from_digit`] (https://doc.rust-lang.org/stable/core/char/fn.from_digit.html) Compatibility Notes ------------------- - [The layout of `repr(Rust)` types now groups m\*2^n-sized fields with equivalently aligned ones.] (rust-lang/rust#102750) This is intended to be an optimization, but it is also known to increase type sizes in a few cases for the placement of enum tags. As a reminder, the layout of `repr(Rust)` types is an implementation detail, subject to change. - [0.5 now rounds to 0 when formatted to 0 decimal places.] (rust-lang/rust#102935) This makes it consistent with the rest of floating point formatting that rounds ties toward even digits. - [Chains of `&&` and `||` will now drop temporaries from their sub-expressions in evaluation order, left-to-right.] (rust-lang/rust#103293) Previously, it was "twisted" such that the _first_ expression dropped its temporaries _last_, after all of the other expressions dropped in order. - [Underscore suffixes on string literals are now a hard error.] (rust-lang/rust#103914) This has been a future-compatibility warning since 1.20.0. - [Stop passing `-export-dynamic` to `wasm-ld`.] (rust-lang/rust#105405) - [`main` is now mangled as `__main_void` on `wasm32-wasi`.] (rust-lang/rust#105468) - [Cargo now emits an error if there are multiple registries in the configuration with the same index URL.] (rust-lang/cargo#10592) Internal Changes ---------------- These changes do not affect any public interfaces of Rust, but they represent significant improvements to the performance or internals of rustc and related tools. - [Rewrite LLVM's archive writer in Rust.] (rust-lang/rust#97485)

remove no-op 'let _ = ' Also see the discussion at rust-lang/rust#93563 (comment). I don't know why these `Drop` implementations exist to begin with, given that their body does literally nothing, but did not want to change that. (It might affect dropck.) Cc `````@ibraheemdev````` `````@Amanieu`````

This removes a large dependency which should improve our build speed a bit. Note: mpsc::channel is now a port of crossbeam, they have no difference. See: `https://github.com/rust-lang/rust/pull/93563`

Pkgsrc changes: * Adjust patches (add & remove) and cargo checksums to new versions. * It's conceivable that the workaround for LLVM based NetBSD works even less in this version (ref. PKGSRC_HAVE_LIBCPP not having a corresponding patch anymore). Upstream changes: Version 1.68.2 (2023-03-28) =========================== - [Update the GitHub RSA host key bundled within Cargo] (rust-lang/cargo#11883). The key was [rotated by GitHub] (https://github.blog/2023-03-23-we-updated-our-rsa-ssh-host-key/) on 2023-03-24 after the old one leaked. - [Mark the old GitHub RSA host key as revoked] (rust-lang/cargo#11889). This will prevent Cargo from accepting the leaked key even when trusted by the system. - [Add support for `@revoked` and a better error message for `@cert-authority` in Cargo's SSH host key verification] (rust-lang/cargo#11635) Version 1.68.1 (2023-03-23) =========================== - [Fix miscompilation in produced Windows MSVC artifacts] (rust-lang/rust#109094) This was introduced by enabling ThinLTO for the distributed rustc which led to miscompilations in the resulting binary. Currently this is believed to be limited to the -Zdylib-lto flag used for rustc compilation, rather than a general bug in ThinLTO, so only rustc artifacts should be affected. - [Fix --enable-local-rust builds] (rust-lang/rust#109111) - [Treat `$prefix-clang` as `clang` in linker detection code] (rust-lang/rust#109156) - [Fix panic in compiler code] (rust-lang/rust#108162) Version 1.68.0 (2023-03-09) =========================== Language -------- - [Stabilize default_alloc_error_handler] (rust-lang/rust#102318) This allows usage of `alloc` on stable without requiring the definition of a handler for allocation failure. Defining custom handlers is still unstable. - [Stabilize `efiapi` calling convention.] (rust-lang/rust#105795) - [Remove implicit promotion for types with drop glue] (rust-lang/rust#105085) Compiler -------- - [Change `bindings_with_variant_name` to deny-by-default] (rust-lang/rust#104154) - [Allow .. to be parsed as let initializer] (rust-lang/rust#105701) - [Add `armv7-sony-vita-newlibeabihf` as a tier 3 target] (rust-lang/rust#105712) - [Always check alignment during compile-time const evaluation] (rust-lang/rust#104616) - [Disable "split dwarf inlining" by default.] (rust-lang/rust#106709) - [Add vendor to Fuchsia's target triple] (rust-lang/rust#106429) - [Enable sanitizers for s390x-linux] (rust-lang/rust#107127) Libraries --------- - [Loosen the bound on the Debug implementation of Weak.] (rust-lang/rust#90291) - [Make `std::task::Context` !Send and !Sync] (rust-lang/rust#95985) - [PhantomData layout guarantees] (rust-lang/rust#104081) - [Don't derive Debug for `OnceWith` & `RepeatWith`] (rust-lang/rust#104163) - [Implement DerefMut for PathBuf] (rust-lang/rust#105018) - [Add O(1) `Vec -> VecDeque` conversion guarantee] (rust-lang/rust#105128) - [Leak amplification for peek_mut() to ensure BinaryHeap's invariant is always met] (rust-lang/rust#105851) Stabilized APIs --------------- - [`{core,std}::pin::pin!`] (https://doc.rust-lang.org/stable/std/pin/macro.pin.html) - [`impl From<bool> for {f32,f64}`] (https://doc.rust-lang.org/stable/std/primitive.f32.html#impl-From-for-f32) - [`std::path::MAIN_SEPARATOR_STR`] (https://doc.rust-lang.org/stable/std/path/constant.MAIN_SEPARATOR_STR.html) - [`impl DerefMut for PathBuf`] (https://doc.rust-lang.org/stable/std/path/struct.PathBuf.html#impl-DerefMut-for-PathBuf) These APIs are now stable in const contexts: - [`VecDeque::new`] (https://doc.rust-lang.org/stable/std/collections/struct.VecDeque.html#method.new) Cargo ----- - [Stabilize sparse registry support for crates.io] (rust-lang/cargo#11224) - [`cargo build --verbose` tells you more about why it recompiles.] (rust-lang/cargo#11407) - [Show progress of crates.io index update even `net.git-fetch-with-cli` option enabled] (rust-lang/cargo#11579) Misc ---- Compatibility Notes ------------------- - [Add `SEMICOLON_IN_EXPRESSIONS_FROM_MACROS` to future-incompat report] (rust-lang/rust#103418) - [Only specify `--target` by default for `-Zgcc-ld=lld` on wasm] (rust-lang/rust#101792) - [Bump `IMPLIED_BOUNDS_ENTAILMENT` to Deny ReportNow] (rust-lang/rust#106465) - [`std::task::Context` no longer implements Send and Sync] (rust-lang/rust#95985) nternal Changes ---------------- These changes do not affect any public interfaces of Rust, but they represent significant improvements to the performance or internals of rustc and related tools. - [Encode spans relative to the enclosing item] (rust-lang/rust#84762) - [Don't normalize in AstConv] (rust-lang/rust#101947) - [Find the right lower bound region in the scenario of partial order relations] (rust-lang/rust#104765) - [Fix impl block in const expr] (rust-lang/rust#104889) - [Check ADT fields for copy implementations considering regions] (rust-lang/rust#105102) - [rustdoc: simplify JS search routine by not messing with lev distance] (rust-lang/rust#105796) - [Enable ThinLTO for rustc on `x86_64-pc-windows-msvc`] (rust-lang/rust#103591) - [Enable ThinLTO for rustc on `x86_64-apple-darwin`] (rust-lang/rust#103647) Version 1.67.0 (2023-01-26) ========================== Language -------- - [Make `Sized` predicates coinductive, allowing cycles.] (rust-lang/rust#100386) - [`#[must_use]` annotations on `async fn` also affect the `Future::Output`.] (rust-lang/rust#100633) - [Elaborate supertrait obligations when deducing closure signatures.] (rust-lang/rust#101834) - [Invalid literals are no longer an error under `cfg(FALSE)`.] (rust-lang/rust#102944) - [Unreserve braced enum variants in value namespace.] (rust-lang/rust#103578) Compiler -------- - [Enable varargs support for calling conventions other than `C` or `cdecl`.] (rust-lang/rust#97971) - [Add new MIR constant propagation based on dataflow analysis.] (rust-lang/rust#101168) - [Optimize field ordering by grouping m\*2^n-sized fields with equivalently aligned ones.] (rust-lang/rust#102750) - [Stabilize native library modifier `verbatim`.] (rust-lang/rust#104360) Added and removed targets: - [Add a tier 3 target for PowerPC on AIX] (rust-lang/rust#102293), `powerpc64-ibm-aix`. - [Add a tier 3 target for the Sony PlayStation 1] (rust-lang/rust#102689), `mipsel-sony-psx`. - [Add tier 3 `no_std` targets for the QNX Neutrino RTOS] (rust-lang/rust#102701), `aarch64-unknown-nto-qnx710` and `x86_64-pc-nto-qnx710`. - [Remove tier 3 `linuxkernel` targets] (rust-lang/rust#104015) (not used by the actual kernel). Refer to Rust's [platform support page][platform-support-doc] for more information on Rust's tiered platform support. Libraries --------- - [Merge `crossbeam-channel` into `std::sync::mpsc`.] (rust-lang/rust#93563) - [Fix inconsistent rounding of 0.5 when formatted to 0 decimal places.] (rust-lang/rust#102935) - [Derive `Eq` and `Hash` for `ControlFlow`.] (rust-lang/rust#103084) - [Don't build `compiler_builtins` with `-C panic=abort`.] (rust-lang/rust#103786) Stabilized APIs --------------- - [`{integer}::checked_ilog`] (https://doc.rust-lang.org/stable/std/primitive.i32.html#method.checked_ilog) - [`{integer}::checked_ilog2`] (https://doc.rust-lang.org/stable/std/primitive.i32.html#method.checked_ilog2) - [`{integer}::checked_ilog10`] (https://doc.rust-lang.org/stable/std/primitive.i32.html#method.checked_ilog10) - [`{integer}::ilog`] (https://doc.rust-lang.org/stable/std/primitive.i32.html#method.ilog) - [`{integer}::ilog2`] (https://doc.rust-lang.org/stable/std/primitive.i32.html#method.ilog2) - [`{integer}::ilog10`] (https://doc.rust-lang.org/stable/std/primitive.i32.html#method.ilog10) - [`NonZeroU*::ilog2`] (https://doc.rust-lang.org/stable/std/num/struct.NonZeroU32.html#method.ilog2) - [`NonZeroU*::ilog10`] (https://doc.rust-lang.org/stable/std/num/struct.NonZeroU32.html#method.ilog10) - [`NonZero*::BITS`] (https://doc.rust-lang.org/stable/std/num/struct.NonZeroU32.html#associatedconstant.BITS) These APIs are now stable in const contexts: - [`char::from_u32`] (https://doc.rust-lang.org/stable/std/primitive.char.html#method.from_u32) - [`char::from_digit`] (https://doc.rust-lang.org/stable/std/primitive.char.html#method.from_digit) - [`char::to_digit`] (https://doc.rust-lang.org/stable/std/primitive.char.html#method.to_digit) - [`core::char::from_u32`] (https://doc.rust-lang.org/stable/core/char/fn.from_u32.html) - [`core::char::from_digit`] (https://doc.rust-lang.org/stable/core/char/fn.from_digit.html) Compatibility Notes ------------------- - [The layout of `repr(Rust)` types now groups m\*2^n-sized fields with equivalently aligned ones.] (rust-lang/rust#102750) This is intended to be an optimization, but it is also known to increase type sizes in a few cases for the placement of enum tags. As a reminder, the layout of `repr(Rust)` types is an implementation detail, subject to change. - [0.5 now rounds to 0 when formatted to 0 decimal places.] (rust-lang/rust#102935) This makes it consistent with the rest of floating point formatting that rounds ties toward even digits. - [Chains of `&&` and `||` will now drop temporaries from their sub-expressions in evaluation order, left-to-right.] (rust-lang/rust#103293) Previously, it was "twisted" such that the _first_ expression dropped its temporaries _last_, after all of the other expressions dropped in order. - [Underscore suffixes on string literals are now a hard error.] (rust-lang/rust#103914) This has been a future-compatibility warning since 1.20.0. - [Stop passing `-export-dynamic` to `wasm-ld`.] (rust-lang/rust#105405) - [`main` is now mangled as `__main_void` on `wasm32-wasi`.] (rust-lang/rust#105468) - [Cargo now emits an error if there are multiple registries in the configuration with the same index URL.] (rust-lang/cargo#10592) Internal Changes ---------------- These changes do not affect any public interfaces of Rust, but they represent significant improvements to the performance or internals of rustc and related tools. - [Rewrite LLVM's archive writer in Rust.] (rust-lang/rust#97485)

Implement `Sync` for `mpsc::Sender` `mpsc::Sender` is currently `!Sync` because the previous implementation contained an optimization where the channel started out as single-producer and was dynamically upgraded on the first clone, which relied on a unique reference to the sender. This optimization is one of the main reasons the old implementation was so complex and was removed in rust-lang#93563. `mpsc::Sender` can now soundly implement `Sync`. Note for any potential confusion, this chance does *not* add MPMC behavior. This only affects the already `Send Clone` *sender*, not *receiver*. It's technically possible to rely on the `!Sync` behavior in the same way as a `PhantomData<*mut T>`, but that seems very unlikely in practice. Either way, this change is insta-stable and needs an FCP. `@rustbot` label T-libs-api -T-libs

HaiyangXu · 2023-09-26T01:46:49Z

do we include this in the rust edition 2021 ?

slanterns · 2023-09-26T03:39:23Z

It has nothing to do with edition. Just use rustc >= 1.67 and you'll get it.

rust-highfive assigned yaahc Feb 1, 2022

rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Feb 1, 2022

ibraheemdev mentioned this pull request Feb 1, 2022

Panic in Receiver::recv() #39364

Closed

joshtriplett added I-libs-api-nominated Nominated for discussion during a libs-api team meeting. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. labels Feb 2, 2022

tavianator mentioned this pull request Feb 2, 2022

Re-introduce crossbeam channels sharkdp/fd#933

Closed

jyn514 mentioned this pull request Feb 2, 2022

mpsc may be crashed as tail is some #60345

Closed

thomcc reviewed Feb 4, 2022

View reviewed changes

m-ou-se removed the I-libs-api-nominated Nominated for discussion during a libs-api team meeting. label Feb 16, 2022

m-ou-se self-requested a review February 16, 2022 23:43

m-ou-se assigned Amanieu and m-ou-se and unassigned yaahc Feb 17, 2022

the8472 mentioned this pull request Mar 2, 2022

Concurrency bugs in mpsc's stream and shared mode #94518

Closed

JohnCSimon added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Apr 11, 2022

james7132 mentioned this pull request Jan 10, 2023

Replace use of crossbeam_channel with std::sync::mpsc bevyengine/bevy#7153

Closed

Diwakar-Gupta mentioned this pull request Feb 3, 2023

Event stream SeaQL/sea-orm#1239

Draft

3 tasks

monthonk mentioned this pull request Feb 13, 2023

Support running in background awslabs/mountpoint-s3#72

Merged

kevinushey mentioned this pull request Feb 15, 2023

amalthea: use crossbeam channels instead of std channels posit-dev/positron#173

Closed

0x5459 mentioned this pull request Feb 17, 2023

[venus-worker] use std channels instead of crossbeam-channel ipfs-force-community/damocles#615

Open

4 tasks

SabrinaJewson mentioned this pull request Mar 26, 2023

Mention that crossbeam-channel as the same algorithm as std nicoburns/blessed-rs#76

Merged

dtolnay mentioned this pull request Jun 9, 2023

Implement Sync for mpsc::Sender #111087

Merged

wathenjiang mentioned this pull request Jul 30, 2023

sync: mpsc performance optimization avoid false sharing tokio-rs/tokio#5829

Merged

steffahn mentioned this pull request Sep 19, 2023

Remove Drop impl of mpsc Receiver and (Sync)Sender #114965

Merged

b-ma mentioned this pull request Oct 1, 2023

(de-)allocation in render thread orottier/web-audio-api-rs#359

Open

11 tasks

fredizzimo mentioned this pull request Nov 15, 2023

fix: event loop shouldn't join the render thread neovide/neovide#2129

Merged

RalfJung mentioned this pull request Feb 25, 2024

Occasional memory leak in mpsc channels #121582

Closed

jmbejar mentioned this pull request Feb 28, 2024

First take on a complete set of commands and responses moxin-org/moly#1

Merged

ramon-bernardo mentioned this pull request Feb 29, 2024

Async events improve Ry-ot/Ryot#85

Closed

gz mentioned this pull request Jun 23, 2024

Switch from crossbeam-channel to std::sync::mpsc::channel. feldera/feldera#1924

Merged

dtolnay removed the I-libs-nominated Nominated for discussion during a libs team meeting. label Sep 9, 2024

Shnatsel mentioned this pull request Oct 16, 2024

Drop flume to reduce dependency footprint now that std has a good channel johannesvollmer/exrs#243

Merged

Ayanekoji mentioned this pull request Oct 28, 2024

Stack overflow at runtime when using Rc<RefCell<T>> in cycle detection algorithm #132263

Closed

Enselic mentioned this pull request Nov 5, 2024

Stack overflow for big types in mpsc channels on separate thread #102246

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Merge crossbeam-channel into `std::sync::mpsc` #93563

Merge crossbeam-channel into `std::sync::mpsc` #93563

ibraheemdev commented Feb 1, 2022 •

edited

Loading

joshtriplett commented Feb 1, 2022

ibraheemdev commented Feb 1, 2022

jyn514 commented Feb 2, 2022

ibraheemdev commented Feb 2, 2022 •

edited

Loading

bjorn3 commented Feb 2, 2022

the8472 commented Feb 2, 2022

SimonSapin commented Feb 3, 2022 •

edited

Loading

thomcc left a comment •

edited

Loading

thomcc Feb 4, 2022

ibraheemdev Oct 17, 2022

thomcc Feb 4, 2022

jonhoo Feb 12, 2022

Amanieu Feb 19, 2022

ibraheemdev Oct 17, 2022

thomcc Feb 4, 2022

thomcc Feb 4, 2022 •

edited

Loading

thomcc Feb 4, 2022

ibraheemdev Oct 17, 2022

thomcc commented Feb 4, 2022

m-ou-se commented Feb 16, 2022

saethlin commented Feb 16, 2022 •

edited

Loading

saethlin commented Feb 17, 2022 •

edited

Loading

kpreid commented Feb 17, 2022

m-ou-se commented Feb 17, 2022

bors commented Mar 11, 2022

HaiyangXu commented Sep 26, 2023

slanterns commented Sep 26, 2023 •

edited

Loading

Merge crossbeam-channel into std::sync::mpsc #93563

Merge crossbeam-channel into std::sync::mpsc #93563

Conversation

ibraheemdev commented Feb 1, 2022 • edited Loading

joshtriplett commented Feb 1, 2022

ibraheemdev commented Feb 1, 2022

jyn514 commented Feb 2, 2022

ibraheemdev commented Feb 2, 2022 • edited Loading

bjorn3 commented Feb 2, 2022

the8472 commented Feb 2, 2022

SimonSapin commented Feb 3, 2022 • edited Loading

thomcc left a comment • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

thomcc Feb 4, 2022 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

thomcc commented Feb 4, 2022

m-ou-se commented Feb 16, 2022

saethlin commented Feb 16, 2022 • edited Loading

saethlin commented Feb 17, 2022 • edited Loading

kpreid commented Feb 17, 2022

m-ou-se commented Feb 17, 2022

bors commented Mar 11, 2022

HaiyangXu commented Sep 26, 2023

slanterns commented Sep 26, 2023 • edited Loading

Merge crossbeam-channel into `std::sync::mpsc` #93563

Merge crossbeam-channel into `std::sync::mpsc` #93563

ibraheemdev commented Feb 1, 2022 •

edited

Loading

ibraheemdev commented Feb 2, 2022 •

edited

Loading

SimonSapin commented Feb 3, 2022 •

edited

Loading

thomcc left a comment •

edited

Loading

thomcc Feb 4, 2022 •

edited

Loading

saethlin commented Feb 16, 2022 •

edited

Loading

saethlin commented Feb 17, 2022 •

edited

Loading

slanterns commented Sep 26, 2023 •

edited

Loading