Motoyuki Kimura

Okay I see. > I guess we could introduce a separate feature flag that specifically enables tokio/tracing Or, we might want to wait for `task::Builder` to stabilize ...

It seems that `disable_keep_alive_mid_request` sometimes fails too. https://github.com/tokio-rs/tokio/actions/runs/17503750269/job/49722717146 ``` failures: ---- disable_keep_alive_mid_request stdout ---- thread '' panicked at tests/server.rs:1205:9: should receive OK response, but buf: [] stack backtrace: 0: __rustc::rust_begin_unwind...

I don't see any harm in adding these metrics as well. Note that some of these metrics are not stabilized yet, so the they could be changed or removed. (See...

@elfenpiff Thank you for your guidance! Yes, I'll probably submit a PR that provides the basic loom setup (e.g., add loom's sync types, introducing cfg, etc). Then we can add...

We could implement `write_all_vectored` but we should probably wait for the [std](https://doc.rust-lang.org/std/io/trait.Write.html#method.write_all_vectored) stabilization. It's unlikely, but it's still possible for std version to change its api.

> Should the documentation also suggest adding -C debug-assertions? That makes sense to me.

Looks like you're using `std::sync::Arc` instead of `loom::sync::Arc`, is that what you would like to do?

Normally the `Arc` from std is not supposed to be used inside the `loom::model`, so I just wanted to check if this was an easy mistake. I haven't looked into...

Thanks, but it looks like some code changes are also needed.