From: Junio C Hamano <gitster@pobox.com>
To: Abhijeet Sonar <abhijeet.nkt@gmail.com>
Cc: Karthik Nayak <karthik.188@gmail.com>,
git@vger.kernel.org, Paul Millar <paul.millar@desy.de>,
Phillip Wood <phillip.wood123@gmail.com>,
Elijah Newren <newren@gmail.com>, Jeff King <peff@peff.net>
Subject: Re: Re* [PATCH v5] describe: refresh the index when 'broken' flag is used
Date: Wed, 26 Jun 2024 09:17:37 -0700 [thread overview]
Message-ID: <xmqqcyo33cgu.fsf@gitster.g> (raw)
In-Reply-To: <xmqqikxv4t1v.fsf_-_@gitster.g> (Junio C. Hamano's message of "Wed, 26 Jun 2024 08:34:04 -0700")
Junio C Hamano <gitster@pobox.com> writes:
> Subject: [PATCH] fsck: clear child_process after failed run_command()
>
> There are two loops that calls run_command() using the same
> child_process struct near the end of cmd_fsck(). 4d0984be (fsck: do
> not reuse child_process structs, 2018-11-12) tightened these code
> paths to reinitialize the structure in order to safely reuse it.
>
> The run-command API makes no promises about what is left in a struct
> child_process after a command finishes, and it's not safe to simply
> reuse it again for a similar command.
>
> Upon failure, run_command() can return without releasing the
> resource held by the child_process structure, which is done by
> calling finish_command() which in turn calls child_process_clear().
Sorry, but I have to take this back.
The error return code paths in the start_command() function does
seem to call clear_child_process(), which means that there is no
need to call clear_child_process() ourselves after a failed
run_command() call.
The need for reinitializing that established by 4d0984be (fsck: do
not reuse child_process structs, 2018-11-12) still stand, so
... the first run ...
run_command(&cp);
/* no need for separate child_process_clear(&cp) */
child_process_init(&cp); /* prepare for reuse */
... setup for the second run ...
strvec_pushv(&cp.args, diff_index_args);
cp.git_cmd = 1;
... full set-up without relying on anything done earlier ...
would still be needed.
Or alternatively, we could do this to ensure that the child_process
structure is always reusable.
run-command.c | 1 +
run-command.h | 6 +++++-
2 files changed, 6 insertions(+), 1 deletion(-)
diff --git c/run-command.c w/run-command.c
index 6ac1d14516..aba250fbe1 100644
--- c/run-command.c
+++ w/run-command.c
@@ -26,6 +26,7 @@ void child_process_clear(struct child_process *child)
{
strvec_clear(&child->args);
strvec_clear(&child->env);
+ child_process_init(child);
}
struct child_to_clean {
diff --git c/run-command.h w/run-command.h
index 55f6631a2a..6e203c22f6 100644
--- c/run-command.h
+++ w/run-command.h
@@ -204,7 +204,8 @@ int start_command(struct child_process *);
/**
* Wait for the completion of a sub-process that was started with
- * start_command().
+ * start_command(). The child_process structure is cleared and
+ * reinitialized.
*/
int finish_command(struct child_process *);
@@ -214,6 +215,9 @@ int finish_command_in_signal(struct child_process *);
* A convenience function that encapsulates a sequence of
* start_command() followed by finish_command(). Takes a pointer
* to a `struct child_process` that specifies the details.
+ * The child_process structure is cleared and reinitialized,
+ * even when the command fails to start or an error is detected
+ * in finish_command().
*/
int run_command(struct child_process *);
next prev parent reply other threads:[~2024-06-26 16:17 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-25 13:35 [PATCH v3] describe: refresh the index when 'broken' flag is used Abhijeet Sonar
2024-06-25 15:59 ` Junio C Hamano
2024-06-25 16:05 ` Junio C Hamano
2024-06-26 11:16 ` Karthik Nayak
2024-06-26 6:11 ` Abhijeet Sonar
2024-06-26 6:37 ` [PATCH v4] " Abhijeet Sonar
2024-06-26 6:50 ` Abhijeet Sonar
2024-06-26 6:52 ` [PATCH v5] " Abhijeet Sonar
2024-06-26 11:30 ` Karthik Nayak
2024-06-26 12:06 ` Abhijeet Sonar
2024-06-26 15:34 ` Re* " Junio C Hamano
2024-06-26 16:17 ` Junio C Hamano [this message]
2024-06-26 17:29 ` Abhijeet Sonar
2024-06-26 17:35 ` Junio C Hamano
2024-06-26 17:45 ` Junio C Hamano
2024-06-26 18:07 ` Abhijeet Sonar
2024-06-26 18:49 ` Junio C Hamano
2024-06-26 20:34 ` Jeff King
2024-06-27 0:33 ` Jeff King
2024-06-26 21:23 ` Karthik Nayak
2024-06-26 14:59 ` Junio C Hamano
2024-06-26 18:31 ` Junio C Hamano
2024-06-26 19:08 ` [PATCH v7] " Abhijeet Sonar
2024-06-26 19:25 ` Abhijeet Sonar
2024-06-27 6:01 ` Abhijeet Sonar
2024-06-27 15:47 ` Junio C Hamano
2024-06-27 17:33 ` Abhijeet Sonar
2024-06-30 16:12 ` Karthik Nayak
2024-07-01 19:06 ` Junio C Hamano
2024-07-02 10:13 ` Karthik Nayak
2024-07-03 18:17 ` Junio C Hamano
2024-07-03 20:41 ` Karthik Nayak
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=xmqqcyo33cgu.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=abhijeet.nkt@gmail.com \
--cc=git@vger.kernel.org \
--cc=karthik.188@gmail.com \
--cc=newren@gmail.com \
--cc=paul.millar@desy.de \
--cc=peff@peff.net \
--cc=phillip.wood123@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.