From: Johannes Sixt <j6t@kdbg.org>
Date: Wed, 05 Aug 2026 17:55:30 GMT
Subject: Re: [PATCH 0/5] Reintroduce writev(3p)
Message-ID: <2952d9a7-c7c0-44c0-a321-7ddad6497a6e@kdbg.org>
In-Reply-To: <xmqqy0ekr0bm.fsf@gitster.g>

Am 05.08.26 um 18:36 schrieb Junio C Hamano:
>>> I think Patrick's writev(2) follows the pattern our previous compat/
>>> routines have taken.  We use real writev(2) where it is available,
>>> and in the fake implementations in compat/ we have comments that
>>> essentially say "the real function offers X, Y, and Z, but we only
>>> want X and Z and do not need Y, so this implementation does not
>>> support Y".

> A different way to put the same question is "what is Y in the
> context of the intended uses of writev(2) in our codebase"?
The Y that I am thinking of primarily is the atomicity guarantee:

> The  data transfers performed by readv() and writev() are atomic: the
> data written by writev() is written as a single block that is not
> intermingled with output from writes in  other  processes; [...]

(See `man 2 writev`; this isn't spelled out explicitly in the Open Group
Base Specification.)

This is basically unimplementable by any emulation that has to call
write() multiple times.

-- Hannes