Re: [PATCH v4 1/2] run-command: add an "ungroup" option to run_process_parallel()

[Junio C Hamano <gitster@pobox.com>]

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

>> diff --git a/run-command.c b/run-command.c
>> index a8501e38ceb..324e9548469 100644
>> --- a/run-command.c
>> +++ b/run-command.c
>> @@ -1471,6 +1471,7 @@ enum child_state {
>>  	GIT_CP_WAIT_CLEANUP,
>>  };
>>
>> +int run_processes_parallel_ungroup;
>
> This global variable seems to exist solely to avoid extending the
> signature of `run_processes_parallel_tr2()`. Let's not do that.

It may make the change even noisier, though.

>> @@ -1537,7 +1539,7 @@ static void pp_init(struct parallel_processes *pp,
>>  		    get_next_task_fn get_next_task,
>>  		    start_failure_fn start_failure,
>>  		    task_finished_fn task_finished,
>> -		    void *data)
>> +		    void *data, const int ungroup)
>>  {
>>  	int i;

Marking incoming parameter as const is probably a misfeature in C,
but doing so with file-scope static would not hurt too much, so if
this series needs no further reroll, I'd let it pass.


>>  	for (i = 0; i < n; i++) {
>>  		strbuf_init(&pp->children[i].err, 0);
>>  		child_process_init(&pp->children[i].process);
>> +		if (!pp->pfd)
>
> It would be more logical to test for `pp->ungroup` than for `!pp->pfd`.
> In other instances below, the patch uses `if (ungroup)` instead. Let's not
> flip-flop between those two conditions, but the latter consistently.

I'd be somewhat sympathetic to the aversion to "flip-flop", but I
strongly disagree with you here.

"ungroup" does not have to stay to be the only reason why we do not
allocate the pp->pfd[] array, and what we care here is "if we are
polling for events, then do this initialization to the array", not
"if ungroup -> we must not have the pfd[] array -> so let's skip
it".  We do not have to add more code that depends on that two step
inference when we do not need to.

>> @@ -1606,6 +1614,7 @@ static void pp_cleanup(struct parallel_processes *pp)
>>   */
>>  static int pp_start_one(struct parallel_processes *pp)
>>  {
>> +	const int ungroup = pp->ungroup;
>
> It costs readers a couple of moments when they stumble over code that is
> inconsistent with the existing code. In this instance, I find very little
> value in the `const` qualifier. Actually, this entire line is probably not
> worth having because `pp->ungroup` is just 4 characters longer than
> `ungroup`.
>
> This same comment applies to another hunk below, too.
>
> Things like this do take focus away from reviewing the interesting part of
> the contribution, which in particular in the case of a regression fix that
> many are waiting for is something to avoid.

OK.

Thanks.