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

[Patrick Steinhardt <ps@pks.im>]

On Thu, Aug 06, 2026 at 01:26:21PM -0700, Junio C Hamano wrote:
> Patrick Steinhardt <ps@pks.im> writes:
> 
> > On Wed, Aug 05, 2026 at 01:29:44PM -0700, Junio C Hamano wrote:
> >> Johannes Sixt <j6t@kdbg.org> 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 ;-).

Yeah, exactly. The overflow check I think we should keep though to be
closer to the POSIX requirements.

Patrick