From: Junio C Hamano <gitster@pobox.com>
To: Stefan Beller <sbeller@google.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH 2/5] run-command: Call get_next_task with a clean child process.
Date: Tue, 20 Oct 2015 11:49:10 -0700 [thread overview]
Message-ID: <xmqq61218jfd.fsf@gitster.mtv.corp.google.com> (raw)
In-Reply-To: <1445279086-31066-3-git-send-email-sbeller@google.com> (Stefan Beller's message of "Mon, 19 Oct 2015 11:24:43 -0700")
Stefan Beller <sbeller@google.com> writes:
> If the `get_next_task` did not explicitly called child_process_init
I locally did "If get_next_task did not explicitly call child_process_init"
> and only filled in some fields, there may have been some stale data
> in the child process. This is hard to debug and also adds a review
> burden for each new user of that API. To improve the situation, we
> pass only cleanly initialized child structs to the get_next_task.
>
> Signed-off-by: Stefan Beller <sbeller@google.com>
> ---
Again this makes sense.
Another way, which I suspect may be conceptually cleaner, would be
to do this clean-up where pp->children[i].in_use is set to false, as
that is where the particular task is declared to be available for
reuse. That location should be responsible to ensure that the task
indeed is reusable by calling child_process_init().
By the way, does child_process_init() leak old argv/env arrays, or
have they already been cleared by calling finish_command() when we
come to this codepath?
> run-command.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/run-command.c b/run-command.c
> index 8f47c6e..b8b5747 100644
> --- a/run-command.c
> +++ b/run-command.c
> @@ -1010,6 +1010,8 @@ static int pp_start_one(struct parallel_processes *pp)
> if (i == pp->max_processes)
> die("BUG: bookkeeping is hard");
>
> + child_process_init(&pp->children[i].process);
> +
> if (!pp->get_next_task(&pp->children[i].data,
> &pp->children[i].process,
> &pp->children[i].err,
next prev parent reply other threads:[~2015-10-20 18:49 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-19 18:24 [PATCH 0/5] Fixes for the parallel processing Stefan Beller
2015-10-19 18:24 ` [PATCH 1/5] run-command: Fix early shutdown Stefan Beller
2015-10-20 18:41 ` Junio C Hamano
2015-10-19 18:24 ` [PATCH 2/5] run-command: Call get_next_task with a clean child process Stefan Beller
2015-10-20 18:49 ` Junio C Hamano [this message]
2015-10-20 19:07 ` Stefan Beller
2015-10-19 18:24 ` [PATCH 3/5] run-command: Initialize the shutdown flag Stefan Beller
2015-10-19 18:24 ` [PATCH 4/5] test-run-command: test for gracefully aborting Stefan Beller
2015-10-19 18:24 ` [PATCH 5/5] test-run-command: Increase test coverage Stefan Beller
2015-10-20 18:53 ` Junio C Hamano
2015-10-20 19:05 ` Stefan Beller
2015-10-20 17:51 ` [PATCH 6/5] run-command: Fix missing output from late callbacks Stefan Beller
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=xmqq61218jfd.fsf@gitster.mtv.corp.google.com \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=sbeller@google.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.