Re: Git 2.54.0-rc1, subtests of t5310, t5326, t5327

From: brian m. carlson <sandals@crustytoothpaste.net>
Date: Apr 9, 2026, 00:20 UTC
Message-ID: <adbwyvQ-R2Ag1vox@fruit.crustytoothpaste.net>
In-Reply-To: <20260408223233.GB2873736@coredump.intra.peff.net>

On 2026-04-08 at 22:32:33, Jeff King wrote:

Show 12 quoted lines

> 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