File: is `Read::read_vectored`, always a single call to `readv`

We've been having a discussion in the fuser crate about the guarantees provided by std::fs::File on UNIX. The current implementation as it stands means that a single call to Read::read_vectored corresponds to a single call to readv. Similarly for Write::write_vectored and writev:

https://github.com/rust-lang/rust/blob/d95d4f0189e02ac2cd9056a0b39b0d5ab94fe69e/library/std/src/fs.rs#L615-L617
https://github.com/rust-lang/rust/blob/d95d4f0189e02ac2cd9056a0b39b0d5ab94fe69e/library/std/src/sys/unix/fs.rs#L831-L833
https://github.com/rust-lang/rust/blob/d95d4f0189e02ac2cd9056a0b39b0d5ab94fe69e/library/std/src/sys/unix/fd.rs#L94-L103

This is an important property for us as the FUSE device doesn't behave like a regular file in that it atomically delivers a single message with each read. Similarly replies must be sent atomically with a single call to writev

So the question is: is this 1 to 1 read_vectored to readv property guaranteed into the future, at least with std::fs::File and on Linux, MacOS and the BSDs? or should we wrap the file and call libc::writev and libc::readv ourselves?

It's not guaranteed to use readv in the sense that if readv2 existed it could use that, but the docs of read_vectored state:

This method must behave equivalently to a single call to read with concatenated buffers.

So I'm pretty sure that you can rely on the reads/writes being atomic.

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.