Open
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 File
s 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.
Metadata
Metadata
Assignees
Labels
Type
Projects
Milestone
Relationships
Development
No branches or pull requests
Activity
retep998 commentedon Apr 12, 2020
Windows actually does not support vectored reads and writes for anything other than sockets, so
write_vectored
andread_vectored
for 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_at
andwrite_vectored_at
cannot be implemented in a similar fashion, where it does a simpleread_at
orwrite_at
of 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-io
crate 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,
preadv
andpwritev
are "nonstandard, but present also on the modern BSDs". In fact, not all unix supportpreadv
andpwritev
- macOS does not yet.Further, "
preadv
andpwritev
first 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
#![feature(unix_file_vectored_at)]
(#89517).#![feature(unix_file_vectored_at)]
#89517