Git development
 help / color / mirror / Atom feed
From: Justin Tobler <jltobler@gmail.com>
To: Patrick Steinhardt <ps@pks.im>
Cc: git@vger.kernel.org
Subject: Re: [PATCH 2/7] odb/streaming: drop `is_finished` field
Date: Tue, 4 Aug 2026 12:46:56 -0500	[thread overview]
Message-ID: <anIXut41fFzRcyOI@denethor> (raw)
In-Reply-To: <20260804-pks-odb-stream-unification-v1-2-86d70e82345e@pks.im>

On 26/08/04 09:25AM, Patrick Steinhardt wrote:
> The `is_finished` field is used to track whether a write stream is done
> writing all of its data. Tracking this field as part of the stream
> itself shouldn't be required though: callers will already know when the
> stream is done when the stream's read function returns zero bytes, same
> as when reading from a file descriptor.
> 
> There is one exception where it gets a bit more complicated: when
> consuming data in "builtin/unpack-objects.c" it may happen that we don't
> yield any new bytes after reading from the pipe. This is addressed by
> looping until we have produced at least a single byte of output.

Addressing this one outlier sounds reasonable.

> Drop the field from `struct odb_write_stream`. Again, same as in the
> preceding commit, this brings the structure a bit closer to its sibling
> `struct odb_read_stream`.

This also makes the overal interface a bit simpler. Callers can trust
that when `odb_write_stream_read()` returns zero, it is actually
finished without having to inspect further.

> Signed-off-by: Patrick Steinhardt <ps@pks.im>
> ---
>  builtin/unpack-objects.c      | 15 ++++++++-------
>  object-file.c                 | 13 ++++++++-----
>  odb/source-inmemory.c         |  9 ++++++++-
>  odb/source-loose.c            | 12 ++++++++----
>  odb/streaming.c               |  5 +----
>  odb/streaming.h               |  1 -
>  t/unit-tests/u-odb-inmemory.c |  5 +++--
>  7 files changed, 36 insertions(+), 24 deletions(-)
> 
> diff --git a/builtin/unpack-objects.c b/builtin/unpack-objects.c
> index f3e0b504f4..b7c486ea94 100644
> --- a/builtin/unpack-objects.c
> +++ b/builtin/unpack-objects.c
> @@ -368,20 +368,20 @@ static ssize_t feed_input_zstream(struct odb_write_stream *in_stream,
>  {
>  	struct input_zstream_data *data = in_stream->data;
>  	git_zstream *zstream = data->zstream;
> -	void *in = fill(1);
>  
> -	if (in_stream->is_finished)
> +	if (data->status != Z_OK)
>  		return 0;
>  
>  	zstream->next_out = buf;
>  	zstream->avail_out = buf_len;
> -	zstream->next_in = in;
> -	zstream->avail_in = len;
>  
> -	data->status = git_inflate(zstream, 0);
> +	while (data->status == Z_OK && zstream->avail_out == buf_len) {
> +		zstream->next_in = fill(1);
> +		zstream->avail_in = len;
> +		data->status = git_inflate(zstream, 0);
> +		use(len - zstream->avail_in);
> +	}

Ok, now we call `git_inflate()` in a loop until there is an error or we
get some data back. This makes it so we can trust that returning zero
does mean that the stream is finished. Previously, it was the callers
responsibility to check the `is_finished` stream field to be certain.

I was curious if we needed to update any code documentation with this
change, but it looks like the comments for `odb_write_stream_read()`
already made it sound like this was the current behavior.

[snip]
> diff --git a/odb/streaming.h b/odb/streaming.h
> index 4d7d31b5aa..5e8e6e532e 100644
> --- a/odb/streaming.h
> +++ b/odb/streaming.h
> @@ -56,7 +56,6 @@ struct odb_write_stream {
>  	ssize_t (*read)(struct odb_write_stream *, unsigned char *, size_t);
>  	void *data;
>  	size_t size;
> -	int is_finished;

The field is dropped. Nice.

The rest of this patch looks good.

-Justin

  reply	other threads:[~2026-08-04 17:47 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-04  7:25 [PATCH 0/7] odb: unify read and write streams Patrick Steinhardt
2026-08-04  7:25 ` [PATCH 1/7] odb/streaming: track write stream size in the structure Patrick Steinhardt
2026-08-04 16:47   ` Justin Tobler
2026-08-04  7:25 ` [PATCH 2/7] odb/streaming: drop `is_finished` field Patrick Steinhardt
2026-08-04 17:46   ` Justin Tobler [this message]
2026-08-04  7:25 ` [PATCH 3/7] odb/streaming: support streaming arbitrary object types Patrick Steinhardt
2026-08-04 18:03   ` Justin Tobler
2026-08-05  6:06     ` Patrick Steinhardt
2026-08-04 18:54   ` Junio C Hamano
2026-08-05  6:06     ` Patrick Steinhardt
2026-08-04  7:25 ` [PATCH 4/7] odb/streaming: rename `struct odb_read_stream` Patrick Steinhardt
2026-08-04  7:25 ` [PATCH 5/7] odb/streaming: consolidate read and write streams Patrick Steinhardt
2026-08-04 18:23   ` Justin Tobler
2026-08-05  6:06     ` Patrick Steinhardt
2026-08-04  7:25 ` [PATCH 6/7] odb/streaming: rename `struct read_object_fd_data` Patrick Steinhardt
2026-08-04 18:25   ` Justin Tobler
2026-08-04  7:25 ` [PATCH 7/7] odb/streaming: unify function names to create new streams Patrick Steinhardt
2026-08-04 18:30   ` Justin Tobler
2026-08-05  7:44 ` [PATCH v2 0/8] odb: unify read and write streams Patrick Steinhardt
2026-08-05  7:44   ` [PATCH v2 1/8] odb/streaming: track write stream size in the structure Patrick Steinhardt
2026-08-05  7:44   ` [PATCH v2 2/8] odb/streaming: drop `is_finished` field Patrick Steinhardt
2026-08-05  7:44   ` [PATCH v2 3/8] odb/streaming: support streaming arbitrary object types Patrick Steinhardt
2026-08-05  7:44   ` [PATCH v2 4/8] odb/streaming: rename `struct odb_read_stream` Patrick Steinhardt
2026-08-05  7:44   ` [PATCH v2 5/8] odb/streaming: consolidate read and write streams Patrick Steinhardt
2026-08-05  7:44   ` [PATCH v2 6/8] odb/streaming: rename `struct read_object_fd_data` Patrick Steinhardt
2026-08-05  7:44   ` [PATCH v2 7/8] odb/streaming: rename `struct input_zstream_data` Patrick Steinhardt
2026-08-05  7:44   ` [PATCH v2 8/8] odb/streaming: unify function names to create new streams Patrick Steinhardt

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=anIXut41fFzRcyOI@denethor \
    --to=jltobler@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=ps@pks.im \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox