On 2026-04-08 at 22:32:33, Jeff King wrote:
> I think writev() is buying us something when it works (it is hlving the
> number of writes for sideband packets). And it works when either:
> 
>   1. the platform is OK with writing up to 64k in a single writev()
> 
>   2. the platform has a limit that is small (like NonStop here), but
>      writes less than MAX_IO_SIZE work and will save a write() call
> 
> If we just care about (1), then the right solution is to declare that
> writev() isn't fully functional for us on some platforms, and they
> should build with NO_WRITEV. And we should probably embed that in
> config.mak.uname.

Looking at POSIX, there doesn't seem to be any constraints on the size
of individual vectors other than that they must total to less than
SSIZE_MAX.  iovcnt can be limited to 16, but I don't think we're hitting
that here.  POSIX does say that SSIZE_MAX does not need to exceed 32767,
which may be what's going on here, although that does seem like an
unreasonable value for a real system.  Linux, FreeBSD, and NetBSD all
set SSIZE_MAX to either INT_MAX or LONG_MAX.

I also think that 64 KiB is more than reasonable in terms of the size
that people should be able to send.  I'd personally expect to be able to
send values much larger, at least 512 KiB, and I have code that expects
even larger (16 MiB).

So I'd simply say that for systems that have a constraint on the size
that is "too small", they should just use NO_WRITEV.

However, I don't have a strong opinion on this and if people want to do
the proposal for option 2, that's fine with me.

I will say that we may find ourselves in a pickle with Rust code in the
future if we use `write_vectored` since that will probably just use the
OS implementation, but we can worry about that when we get there.
-- 
brian m. carlson (they/them)
Toronto, Ontario, CA