rust/library/std/src/sync
bors afd7977c85 Auto merge of #93563 - ibraheemdev:crossbeam-channel, r=Amanieu
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 https://github.com/rust-lang/rust/issues/39364. The public API intentionally remains the same.

The reason https://github.com/rust-lang/rust/issues/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 https://github.com/rust-lang/rust/issues/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
2022-11-13 12:08:42 +00:00
..
barrier std: move "mod tests/benches" to separate files 2020-08-31 02:56:59 +00:00
condvar Remove condvar::two_mutexes test. 2022-05-05 21:47:13 +02:00
lazy_lock Move/rename lazy::Sync{OnceCell,Lazy} to sync::{Once,Lazy}Lock 2022-06-16 19:54:42 +04:00
mpmc avoid calling thread::current in channel destructor 2022-11-12 23:13:58 -05:00
mpsc remove mention of rust-lang#39364 from mpsc docs 2022-11-09 23:20:02 -05:00
mutex Use implicit capture syntax in format_args 2022-03-10 10:23:40 -05:00
once Stabilize poison API of Once, rename poisoned() 2021-02-04 15:20:14 +01:00
once_lock Move/rename lazy::Sync{OnceCell,Lazy} to sync::{Once,Lazy}Lock 2022-06-16 19:54:42 +04:00
rwlock make many std tests work in Miri 2022-08-18 18:07:39 -04:00
barrier.rs Rollup merge of #87440 - twetzel59:fix-barrier-no-op, r=yaahc 2021-10-21 14:11:02 +09:00
condvar.rs std: remove lock wrappers in sys_common 2022-11-06 15:32:59 +01:00
lazy_lock.rs Move/rename lazy::Sync{OnceCell,Lazy} to sync::{Once,Lazy}Lock 2022-06-16 19:54:42 +04:00
mod.rs initial port of crossbeam-channel 2022-11-09 23:18:06 -05:00
mutex.rs std: remove lock wrappers in sys_common 2022-11-06 15:32:59 +01:00
once.rs std: use futex in Once 2022-10-07 12:12:36 +02:00
once_lock.rs std: make ReentrantMutex movable and const; simplify Stdout initialization 2022-09-03 14:05:28 +02:00
poison.rs Auto merge of #97791 - m-ou-se:const-locks, r=m-ou-se 2022-06-19 08:20:36 +00:00
rwlock.rs std: remove lock wrappers in sys_common 2022-11-06 15:32:59 +01:00