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

From: Junio C Hamano <gitster@pobox.com>
Date: Apr 8, 2026, 22:24 UTC
Message-ID: <xmqqzf3dw0o8.fsf@gitster.g>
In-Reply-To: <xmqqcy09xh53.fsf@gitster.g>

Junio C Hamano <gitster@pobox.com> writes:

Show 8 quoted lines

> To be quite honest, I am not sure if it is even worth using writev()
> if we need a loop that protects against shrot writes, so unless I am
> grossly mistaken (e.g., perhaps there is some guarantee that there
> won't be any short writes for writev() that sends data smaller than
> 64k that I missed in the docs), the best course of action might be
> to revert the change to use writev() and use the two write(2)s as
> before, *if* we actually observe that the current code is broken by
> short writes.

Ah, sorry, I should have double checked the actual code. We already use a looping writev_in_full() that wraps writev(), so there is nothing extra that we still need to do to prepare for short writes.

Unfortunately, comparing write_in_full() vs writev_in_full(), there is nothing that corresponds to xwrite() that can be used to hide the short writes and chomps an originally larger I/O into smaller pieces. Unlike write() that we may receive a single linear large sequence of bytes, which we can choose to chomp into artificially smaller pieces and write them out (up to 8MB by default), writev() API lets the caller to prepare chunks of memory and I do not think there is a good way for the writev_in_full() at the lower layer to chomp these into smaller pieces, and even if we could, that would defeat the whole reason why we rewrote the original code that used write_in_full() into using writev(), i.e., to avoid extra allocation (and extra system calls---but if your I/O layer is limited to very small writes, no matter how we chop it, you will have to issue extra system calls to flush all of the data out).

So, I dunno.