Repository navigation
Support positional vectored IO for unix files #71055
Description
Next to the existing write_vectored and read_vectored APIs, it would be great to have write_vectored_at and read_vectored_at methods for Files on UNIX systems, corresponding to the pwritev and preadv syscalls. This would be an easy way to add means for high performance file IO using the standard library File type.
As far as I understand, the equivalent does not exist on Windows, so this would probably have to live in the unix FileExt trait.
If this is deemed desirable, I'd be happy to send a PR for this.
Activity
retep998 commentedon Apr 12, 2020
Windows actually does not support vectored reads and writes for anything other than sockets, so
write_vectoredandread_vectoredfor files just defaults to doing a single read/write of the first buffer. Windows does support reading and writing at a specific position, so I see no reason whyread_vectored_atandwrite_vectored_atcannot be implemented in a similar fashion, where it does a simpleread_atorwrite_atof the first buffer.vimpunk commentedon Apr 15, 2020
@retep998 Thanks for the clarification. In that case this could indeed be implemented for Windows as well.
I suppose the next step would be an RFC?
alecmocatta commentedon Apr 16, 2020
Positional reading/writing on Windows has the unfortunate effect of modifying the file offset cursor. IIRC the
positioned-iocrate has either of two workarounds: storing the cursor explicitly, or using a temporary memory mapping to read data rather thanFileExt::seek_read.superobertking commentedon Apr 26, 2020
Citing from Linux man page,
preadvandpwritevare "nonstandard, but present also on the modern BSDs". In fact, not all unix supportpreadvandpwritev- macOS does not yet.Further, "
preadvandpwritevfirst appeared in Linux 2.6.30 and library support was added in glibc 2.10", while the Rust platform support requires the minimal Linux version of 2.6.18. This would break backward compatibility support.For non-POSIX standard API, it's better to reside in an external crate rather than in the std as suggested (in somewhere else I cannot find now). Libc already provides this syscall function, and nix provides a pretty wrapper function around it. I guess we could have a
FileExt-like trait in some crate and implement it for the std File.artob commentedon Oct 10, 2023
This was implemented in #89518, feature gated by
#.