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

[Junio C Hamano <gitster@pobox.com>]

Johannes Sixt <j6t@kdbg.org> 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.

Thanks.

PS.  I was going over the list of "waiting for response" topics, and
this was one of them.  I suspect Patrick and the GitLab team are
still away at an offsite [*], so this is in no way poking him for an
immediate reroll, but rather a note sent while my attention is on
these stalled topics.

https://lore.kernel.org/git/amLgMqkqxR8mKIbT@pks.im/