Taiki Endo

Oh, a lot of conflicts...

Seems AtomicWaker is not actually UnwindSafe. e.g., If the following clone panicked, AtomicWaker will probably not work well. https://github.com/rust-lang/futures-rs/blob/c77cd3c9ba19b65db3d1931d2087032752fe9c7d/futures-core/src/task/__internal/atomic_waker.rs#L267 see also https://github.com/tokio-rs/tokio/pull/3689

clone can cause panic because [you can pass a function that can cause panic](https://doc.rust-lang.org/stable/core/task/struct.RawWakerVTable.html#clone).

We can allow this once the lint like the one that [this shiny future story](https://rust-lang.github.io/wg-async-foundations/vision/shiny_future/barbara_enjoys_an_async_sandwich.html) mentions is implemented.

IIRC limitation is: https://github.com/rust-lang/futures-rs/issues/1776#issuecomment-518307092 However, a recent compiler change (probably in 1.52) may have fixed this.

The current MSRV for `futures`/`futures-util` is 1.41, and for some crates, such as `futures-core`, which provides only traits, the MSRV is 1.36. The MSRV policy for `futures`/`futures-util` is basically ["whatever...

Thanks! It seems the previous attempt had performance issue, so I'm curious if this implementation fixed that issue.

FWIW, results on my MacBook Pro (Intel Core i7-9750H, macOS v11.2.3). old (2be999da) ``` test bench::concurrent ... bench: 4,328,809 ns/iter (+/- 2,353,379) test bench::contended ... bench: 94,411 ns/iter (+/- 12,618)...

> Given that this is a Rust project, it has to be a Rust team. I would call this a joint decision of @rust-lang/libs and @rust-lang/lang, though probably more libs...

As far as I know, this is the only issue that has been controversial and not fully been resolved, except for release timing. So, for other areas, we will proceed...