Re: [PATCH 0/5] Reintroduce writev(3p)

On Wed, Aug 05, 2026 at 01:29:44PM -0700, Junio C Hamano wrote:

Johannes Sixt [off-list ref] writes:

quoted

Am 05.08.26 um 20:40 schrieb Junio C Hamano:

quoted

I think it is OK to explicitly document that any writev(2) emulation
is allowed to be non-atomic, and it is also OK to declare that using
writev(2) in this application to allow competing writes to the same
destination is a bug.

These are fine.

But I'm not worried about current uses of writev, I'm worried about
future uses: "Look, we already use writev elsewhere. Let's use it here,
too, where we can take adavantage of the atomicity of the write." It's
too easy to miss a note about non-atomic emulations when the function
name advertises more than can be guaranteed. For this reason, I strongly
suggest to use a different name.

That is why I added the "it is also OK to declare" in the above.

We could of course trivially restore the non-interleaving property by
only ever writing the first iovec. POSIX doesn't guarantee that the full
iovec is being written, and write(3p) is already non-interleaving. It
wouldn't even be less efficient compared to the current implementation,
as we have to loop around write(3p) anyway in our compatibility wrapper.

Patrick