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

Patrick Steinhardt <[email protected]> writes:

> On Wed, Aug 05, 2026 at 01:29:44PM -0700, Junio C Hamano wrote:
>> Johannes Sixt <[email protected]> writes:
>> 
>> > Am 05.08.26 um 20:40 schrieb Junio C Hamano:
>> >> 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.

OK, by castrating the writev(2) emulation implementation to write
out only the first iovec[], we are making the emulation "atomic", so
there is no need to say "your emulation does not have to be atomic"
and we can rely on being able to pretend that we have writev(2)
available everywhere.  Also, it is a bug on the programmers' side to
assume that their writev() calls will not result in a short write,
so it does not have to be spelled out, either, which automatically
means you'd better be calling writev_in_full() and not writev()
itself.

I can buy that.  Clever.  It means we'd need an update for [PATCH
1/5] 1ed0bc4e3b (compat/posix: introduce writev(3p) wrapper,
2026-07-16), right?  The update would be a simplification that loses
a lot of code (and overflow check), which is even nicer ;-).