Motoyuki Kimura
Motoyuki Kimura
This doesn't seem like a random occurrence, I'll take a look into it.
To fix https://github.com/tokio-rs/tokio/pull/7321#pullrequestreview-2973357507, I opened another PR https://github.com/tokio-rs/tokio/pull/7436 since it's somewhat unrelated to `open` support itself.
I'll be back soon and address the comments.
My guess is that if the scheduling of the async task differs between `loom::future::block_on` and `shuttle::future::block_on`, it could produce different results.
Hi, I'm happy to review this, but it might take a bit of time since it's been a while since I last looked at the code.
I don't know much about the Helgrind, so I can't say well about the comparison. As for loom, it uses the DPOR algorithm, where it switches threads or not whenever...
Hmm, I think other crates can provide similar features, so I'm not sure if we should include this in tokio.
I believe it's generally better not to include functionality in tokio that can be implemented in other crates.
Hmm, it looks like the loom failure log is not showing up on ci? ... I captured this locally anyway: logs ``` running 1 test test runtime::tests::loom_multi_thread::group_c::pool_shutdown has been running...
Cargo cannot conditionally enable `tokio/tracing` based on `--cfg tokio_unstable`, but since tokio's tracing feature itself is always gated by `--cfg tokio_unstable`, I guess it doesn't really matter?