Qi
We may need to wait for a new release of `lock_api`. Related issue: .
Upstream has fixed this issue, we need to bump the MSRV to 1.71 and also wait for a new release of upstream.
The latest `parking_lot` has fixed this issue. We still need to wait for .
https://github.com/tokio-rs/tokio/blob/ab3ff69cf2258a8c696b2dca89a2cef4ff114c1c/tokio-test/src/io.rs#L360-L368 https://github.com/tokio-rs/tokio/blob/ab3ff69cf2258a8c696b2dca89a2cef4ff114c1c/tokio-test/src/io.rs#L408-L416 `poll_read` and `poll_write` poll the exact same `Sleep`, so we can consider this timeline. 1. `send.write_u8(0).await` 2. `poll_write` registers a timer. 3. `poll_write` polls the registered `Sleep`, and...
> i was suggested to add a warning to split, what do you think of the following: > /// # Warning > /// > /// Using `split` with certain mock...
> Would stabilizing this allow for scoped tasks - spawning futures without the `'static` bound? [#3162](https://github.com/tokio-rs/tokio/issues/3162) No, the `LocalRuntime` still requires the `'static` bound.
This is `mio`'s waker on unix, see . Did this cause problems? Otherwise, I'm not going to consider this is a bug.
In short, `block_on` always needs to block the current thread, but `rt.spawn` doesn't, so they use different wake up logic.
This addition single byte write is used for waking up the parked I/O driver on unix, it always has performance impact, but should not be noticeable. @lrowe Does this single...
This breaks the MSRV, current MSRV is Rust 1.70, this requires 1.83.