threads / patch / 46423

patchrun_processes_parallel: change confusing task_cb convention

Subject: [PATCH] run_processes_parallel: change confusing task_cb convention

## tl;dr

2 messages between Jul 19, 2017 and Jul 19, 2017. Diffs are folded; open one to read it.

replies: 1people: 2as markdown or json

Johannes Schindelin· Jul 19, 2017, 14:56 UTC · lore

By declaring the task_cb parameter of type `void **`, the signature of the get_next_task method suggests that the "task-specific cookie" can be defined in that method, and the signatures of the start_failure and of the task_finished methods declare that parameter of type `void *`, suggesting that those methods are mere users of said cookie.

That convention makes a total lot of sense, because the tasks are pretty much dead when one of the latter two methods is called: there would be little use to reset that cookie at that point because nobody would be able to see the change afterwards.

However, this is not what the code actually does. For all three methods, it passes the *address* of pp->children[i].data.

As reasoned above, this behavior makes no sense. So let's change the implementation to adhere to the convention suggested by the signatures.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
 builtin/submodule--helper.c | 2 +-
 run-command.c               | 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)
Show changes to 2 files +3 −3

builtin/submodule--helper.c, run-command.c

diff --git a/builtin/submodule--helper.c b/builtin/submodule--helper.c
index 6abdad3294c..3a3c9ca72b6 100644
--- a/builtin/submodule--helper.c
+++ b/builtin/submodule--helper.c
@@ -930,7 +930,7 @@ static int update_clone_task_finished(int result,
 	const struct cache_entry *ce;
 	struct submodule_update_clone *suc = suc_cb;
 
-	int *idxP = *(int**)idx_task_cb;
+	int *idxP = idx_task_cb;
 	int idx = *idxP;
 	free(idxP);
 
diff --git a/run-command.c b/run-command.c
index 9e36151bf97..b5e6eb37c0e 100644
--- a/run-command.c
+++ b/run-command.c
@@ -1533,7 +1533,7 @@ static int pp_start_one(struct parallel_processes *pp)
 	if (start_command(&pp->children[i].process)) {
 		code = pp->start_failure(&pp->children[i].err,
 					 pp->data,
-					 &pp->children[i].data);
+					 pp->children[i].data);
 		strbuf_addbuf(&pp->buffered_output, &pp->children[i].err);
 		strbuf_reset(&pp->children[i].err);
 		if (code)
@@ -1601,7 +1601,7 @@ static int pp_collect_finished(struct parallel_processes *pp)
 
 		code = pp->task_finished(code,
 					 &pp->children[i].err, pp->data,
-					 &pp->children[i].data);
+					 pp->children[i].data);
 
 		if (code)
 			result = code;

base-commit: cac25fc330fc26050dcbc92c4bfff169a4848e93
-- 
2.13.3.windows.1.13.gaf0c2223da0

Published-As: https://github.com/dscho/git/releases/tag/run-process-parallel-v1
Fetch-It-Via: git fetch https://github.com/dscho/git run-process-parallel-v1
Stefan Beller· Jul 19, 2017, 17:16 UTC · re: Johannes Schindelin · lore

Re: [PATCH] run_processes_parallel: change confusing task_cb convention

On Wed, Jul 19, 2017 at 7:56 AM, Johannes Schindelin <johannes.schindelin@gmx.de> wrote:

Show 18 quoted lines
> By declaring the task_cb parameter of type `void **`, the signature of
> the get_next_task method suggests that the "task-specific cookie" can be
> defined in that method, and the signatures of the start_failure and of
> the task_finished methods declare that parameter of type `void *`,
> suggesting that those methods are mere users of said cookie.
>
> That convention makes a total lot of sense, because the tasks are pretty
> much dead when one of the latter two methods is called: there would be
> little use to reset that cookie at that point because nobody would be
> able to see the change afterwards.
>
> However, this is not what the code actually does. For all three methods,
> it passes the *address* of pp->children[i].data.
>
> As reasoned above, this behavior makes no sense. So let's change the
> implementation to adhere to the convention suggested by the signatures.
>
> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
My bad. Thanks for spotting and fixing!
Reviewed-by: Stefan Beller <sbeller@google.com>

← back to recent threads