From: Junio C Hamano <gitster@pobox.com>
To: <rsbecker@nexbridge.com>
Cc: "'Taylor Blau'" <me@ttaylorr.com>,
"'Randall S. Becker'" <the.n.e.key@gmail.com>,
<git@vger.kernel.org>
Subject: Re: [PATCH v1 1/4] builtin/index-pack.c: change xwrite to write_in_full to allow large sizes.
Date: Mon, 26 Feb 2024 15:46:44 -0800 [thread overview]
Message-ID: <xmqqa5nmkcuz.fsf@gitster.g> (raw)
In-Reply-To: <026b01da6906$4d96f530$e8c4df90$@nexbridge.com> (rsbecker@nexbridge.com's message of "Mon, 26 Feb 2024 17:51:09 -0500")
<rsbecker@nexbridge.com> writes:
>>The code above loops while input_len is non-zero, and correctly
>>decrements it by the number of bytes written by xwrite() after
>>each iteration.
>>
>>Assuming that xwrite()/write(2) works how I think it does on
>>NonStop, I'm not sure I understand why this change is necessary.
>
> NonStop has a limited SSIZE_MAX. xwrite only handles that much so
> anything beyond that gets dropped (not in the above code but in
> other builtins)
xwrite() caps a single write attempt to MAX_IO_SIZE and can return a
short-write, so anything beyound MAX_IO_SIZE will not even be sent
to the underlying write(2). There is a heuristic based on the value
of SSIZE_MAX to define MAX_IO_SIZE in <git-compat-util.h>, and if
the value given by that heuristics is too large for your platform,
you can tweak your own MAX_IO_SIZE (see the comments in that header
file).
The caller of xwrite() must be prepared to see a write return with
value less than the length it used to call the function, either
because of this MAX_IO_SIZE cut-off, or because of the underlying
write(2) returning after a short write. As long as the caller is
prepared, like Taylor pointed out, I am not sure why you'd need to
change it.
next prev parent reply other threads:[~2024-02-26 23:46 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-26 22:05 [PATCH v1 0/4] Change xwrite() to write_in_full() in builtins Randall S. Becker
2024-02-26 22:05 ` [PATCH v1 1/4] builtin/index-pack.c: change xwrite to write_in_full to allow large sizes Randall S. Becker
2024-02-26 22:38 ` Taylor Blau
2024-02-26 22:51 ` rsbecker
2024-02-26 23:46 ` Junio C Hamano [this message]
2024-02-27 0:12 ` rsbecker
2024-02-26 23:30 ` rsbecker
2024-02-26 22:05 ` [PATCH v1 2/4] builtin/receive-pack.c: " Randall S. Becker
2024-02-26 23:02 ` rsbecker
2024-02-26 23:50 ` Junio C Hamano
2024-02-27 0:15 ` rsbecker
2024-02-26 22:05 ` [PATCH v1 3/4] builtin/repack.c: " Randall S. Becker
2024-02-26 23:54 ` Junio C Hamano
2024-02-27 8:20 ` Jeff King
2024-02-27 8:22 ` Jeff King
2024-02-26 22:05 ` [PATCH v1 4/4] builtin/unpack-objects.c: " Randall S. Becker
2024-02-26 23:56 ` Junio C Hamano
2024-02-27 0:18 ` rsbecker
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqqa5nmkcuz.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=me@ttaylorr.com \
--cc=rsbecker@nexbridge.com \
--cc=the.n.e.key@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.