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

[Junio C Hamano <gitster@pobox.com>]

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

> 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.