std::io::LineWriter: cap write_vectored newline scan to avoid quadrat…#155797
std::io::LineWriter: cap write_vectored newline scan to avoid quadrat…#155797devnexen wants to merge 1 commit intorust-lang:mainfrom
Conversation
rustbot
added
S-waiting-on-review
|
rustbot has assigned @Mark-Simulacrum. Use Why was this reviewer chosen?The reviewer was selected based on:
|
devnexen
force-pushed
the
linewritershim_upd
branch
from
40453e0 to
e974bd8
Compare
| // that many slices per call, so newlines past the cap can't influence | ||
| // this attempt anyway. Without the cap, repeated calls from | ||
| // write_all_vectored() make this scan quadratic. | ||
| const MAX_BUFS_TO_SCAN: usize = 1024; |
There was a problem hiding this comment.
For this code to be portable it has to work on all platforms, not just unix.
We do have fn max_iov() in sys::fd::unix, but idk how windows or other OSes behave.
There was a problem hiding this comment.
Fair point — the comment was making a Linux-shaped claim about platform-agnostic code. I looked at sys::fd::*::max_iov() first, but it's a private const fn with no
Windows definition, so reaching it from io::buffered would mean adding a new sys::io::MAX_IOV across every platform module. There's also no single right value to wire
it to: there are two disjoint max_iov()s in tree (fd vs Solid socket) because the limit depends on the transport, and LineWriter is generic over W: Write so it can't
know which applies.
The cap here isn't really about the syscall anyway — it's about not doing more memchr work per call than makes sense. 1024 happens to be the value of UIO_MAXIOV /
IOV_MAX on Linux, the BSDs, Apple, Cygwin, and Solid (same hardcoded number, same reasoning). On POSIX-fallback Unixes (16) or Windows (no cap) it still does its
quadratic-guard job, and write_all_vectored's outer loop keeps things correct.
…ic write_all_vectored.
devnexen
force-pushed
the
linewritershim_upd
branch
from
e974bd8 to
5dcf27d
Compare
4 participants
…ic write_all_vectored.