Ensure non-empty buffers for large vectored I/O by thaliaarchi · Pull Request #138879 · rust-lang/rust (original) (raw)
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.Learn more about bidirectional Unicode characters
[ Show hidden characters]({{ revealButtonHref }})
Operating System: Hermit
Operating system: Unix-like
Status: Awaiting review from the assignee but also interested parties.
Relevant to the library team, which will review and decide on the PR/issue.
labels
rustbot added the T-libs-api
Relevant to the library API team, which will review and decide on the PR/issue.
label
readv
and writev
are constrained by a platform-specific upper bound
on the number of buffers which can be passed. Currently, read_vectored
and write_vectored
implementations simply truncate to this limit when
larger. However, when the only non-empty buffers are at indices above
this limit, they will erroneously return Ok(0)
.
Instead, slice the buffers starting at the first non-empty buffer. This trades a conditional move for a branch, so it's barely a penalty in the common case.
The new method limit_slices
on IoSlice
and IoSliceMut
may be
generally useful to users like advance_slices
is, but I have left it
as pub(crate)
for now.
POSIX requires at least one buffer passed to readv and writev, but we allow the user to pass an empty slice of buffers. In this case, return a zero-length read or write.