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

Johannes Sixt <[email protected]> writes:

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

Looking at hits from 'git grep -e writev seen', the only two places
we use writev() or write_gather() are:

 - fast-import, where we write out concatenation of the object
   header, the payload, and the trailing newline in three separate
   buffers in one go; and

 - sideband, where we send the length and band designator in one
   buffer and the payload in another in one go.

Neither use would work at all if we had competing writers working in
parallel to write to the same pipe, regardless of whether atomicity
is guaranteed.

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.