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

On Mon, Jul 27, 2026 at 08:44:39AM -0700, Junio C Hamano wrote:
> Johannes Sixt <[email protected]> writes:
> 
> > Am 16.07.26 um 09:52 schrieb Patrick Steinhardt:
> >> this patch series reintroduces the writev(3p) wrapper. This wrapper was
> >> originally introduced as part of Git 2.54 [1], but was ejected due to
> >> issues on NonStop [2].
> >
> > Please don't call the function "writev" so that nobody associates it
> > with the guarantees that only POSIX provides, but none of the
> > emulations. Call it "write_gather", for example.
> >
> > Also, clearly document that its only purpose is to reduce sequences of
> > write() calls to a single function call, but that the additional writev
> > guarantees are not needed.
> 
> It is philosophically more "pure" to have a two-level abstraction
> where write_gather(), which may be inspired by writev(2) but with
> specific subset of semantics that the application needs, is used by
> the application and have platforms with good enough writev(2) to
> implement it in terms of it.  Other platforms may implement it
> differently, like a series of write(2) calls, and as long as it
> fulfills the need of write_gather(), we are OK.
> 
> Doing so would also help in a minuscule way to avoid adding to the
> complaints we sometimes hear that our internal implementation
> assumes platform support for POSIX API and semantics way too much
> even when we do not need to.
> 
> So I do not mind going in that direction.  It feels a slightly
> roundabout approach, but in the longer run, I think it would place
> us in a much better place.
> 
> 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".  It is harder to maintain because the application side
> may be tempted over time to start depending on Y.  If some platforms
> cannot easily provide an equivalent of the real function, it is
> easier for them if the rules explicitly state from the beginning
> that we do not require and will never require Y, needing only X and
> Z from either the fake or real implementation.
> 
> At that point, we are not describing the real function anymore, so
> your proposal to give it a specific name is one step away from that,
> and that step is in the right direction.

Yeah, I was mostly trying to follow the precedent that we currently have
in our code base, where we assume POSIX functions and paper over any
gaps that a specific platform has via compatibility wrappers. And I
think that the compatibility wrapper we have for writev(3p) is close
enough to the original semantics of it to not really matter much in
practice.

I overall don't disagree that it would've been nice at times to have a
higher-level interface that abstracts over such platform specifics
without assuming POSIX semantics. But I'm not really sure what it buys
us to rename this to `write_gather()` without rethinking the bigger
approach we have to I/O. That is, what does it buy us to now diverge
from the current practice, and where do we want to end up?

I feel like that's a much bigger discussion to be had, and I'm not a
100% sure whether I want to open that can of worms now. If the only
thing that I need to change is to rename from writev to write_gather
then I'm happy to do that. But as said, I don't really think this buys
us much without the bigger discussion, so I'm a bit hesitant to do this.

Patrick