@@ -1495,8 +1495,6 @@ enum child_state {
};
struct parallel_processes {
- void *const data;
-
const size_t max_processes;
size_t nr_processes;
@@ -1607,7 +1605,7 @@ static int pp_start_one(struct parallel_processes *pp,
code = opts->get_next_task(&pp->children[i].process,
opts->ungroup ? NULL : &pp->children[i].err,
- pp->data,
+ opts->data,
&pp->children[i].data);
if (!code) {
if (!opts->ungroup) {
@@ -1626,7 +1624,7 @@ static int pp_start_one(struct parallel_processes *pp,
if (opts->start_failure)
code = opts->start_failure(opts->ungroup ? NULL :
&pp->children[i].err,
- pp->data,
+ opts->data,
pp->children[i].data);
else
code = 0;
@@ -1701,7 +1699,7 @@ static int pp_collect_finished(struct parallel_processes *pp,
if (opts->task_finished)
code = opts->task_finished(code, opts->ungroup ? NULL :
- &pp->children[i].err, pp->data,
+ &pp->children[i].err, opts->data,
pp->children[i].data);
else
code = 0;
@@ -1754,7 +1752,6 @@ void run_processes_parallel(const struct run_process_parallel_opts *opts)
int spawn_cap = 4;
struct parallel_processes pp = {
.max_processes = opts->processes,
- .data = opts->data,
.buffered_output = STRBUF_INIT,
};
/* options */
As with the *_fn members removed in a preceding commit, let's not copy the "data" member of the "struct run_process_parallel_opts" over to the "struct parallel_processes". Now that we're passing the "opts" down there's no reason to do so. This makes the code easier to follow, as we have a "const" attribute on the "struct run_process_parallel_opts", but not "struct parallel_processes". We do not alter the "ungroup" argument, so storing it in the non-const structure would make this control flow less obvious. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> --- run-command.c | 9 +++------ 1 file changed, 3 insertions(+), 6 deletions(-)