`tokio::fs::File::write` returns early before OS says that the operation is completed

[Noratrieb]

Version
latest master

Platform
any

Description

This comes from rust-lang/miri#4367, where we hit this behavior in the Miri test suite.

let mut file = File::create(&path).await?;
file.write_all(b"some bytes").await?;
assert_eq!(file.metadata().await.unwrap().len(), 10);

While of course write_all is not guaranteed to actually flush to disk, the assumption that a single thread of execution sees the results after a write seems to be true for normal sync code (and is very intuitive), but this assumption does not hold for async code using tokio.

Tokio File just does an early return after starting the thread for the write asynchronously.

tokio/tokio/src/fs/file.rs

Line 763 in ab8d7b8

return Poll::Ready(Ok(n));

The code is written in a way that makes this look deliberate, but I could not find documentation about this rather surprising behavior, so consider this more of a documentation request, though of course making it behave consistently would be useful too (but maybe slower?).

[RalfJung]

While of course write_all is not guaranteed to actually flush to disk, the assumption that a single thread of execution sees the results after a write seems to be true for normal sync code

I'm pretty sure POSIX guarantees this for normal sync code. If I wanted a truly async write I'd not await its completion...

So personally I think this is a bug (and not just a docs bug). The entire point of async/await is that I can express what I want to happen concurrently and what I want to be ordered, and by using write_all(...).await, I made that intent quite clear I think.

[Darksonn]

I would implement it the way you suggest if I could, but there's no such implementation that is compatible with the API requirements of AsyncWrite. It's only possible to write an implementation that requires flushing before you can be sure that writes have completed.

[RalfJung]

That sounds like a pretty severe bug in that trait. Is that tracked somewhere so we can avoid copying that mistake into the std version of the trait? Or is there some reason why it's hard to fix this in the trait API requirements?

[Darksonn]

It's because the trait is readiness based. The alternative is completion based IO. You may have heard of this distinction in the context of io_uring, but having IO be backed by spawn_blocking results in the exact same issues.