Subject: Re: [PATCH v7 10/12] run-command: poll child stdin in addition to stdout

From: Adrian Ratiu <[email-masked]>
Date: Tue, 27 Jan 2026 12:10:29 +0200

On Mon, 26 Jan 2026, Junio C Hamano <[email-masked]> wrote:
> Emily Shaffer <[email-masked]> writes:
>
>>> +       /* for each potential child slot, prepare two pollfd entries */
>>> +       for (size_t i = 0; i < opts->processes; i++) {
>>> +               if (child_is_working(&pp->children[i]) &&
>>> +                   pp->children[i].process.err > 0) {
>>
>> I only had the one tiny nit on this patch, which was to wonder if
>> checking for pp->children[i].process.err is something that should also
>> be behind a conveniently-named helper like child_is_working().
>
> We already have
>
>  - child_is_ready_for_cleanup()
>  - child_is_receiving_input()
>  - child_is_working()
>
> What should the "child is working and process.err is positive" be
> called?  child_is_spewing_error()?

Thank you Emily and Junio for the suggestion,

I think "child_is_sending_output" is a good name because:

1. It matches the previous naming convention nicely.

2. all hooks except one (pre-push) have redirected stdout to stderr by
default even in the ungroup/serialized execution case (not relevant for
this code path).

3. all hooks without exception do the stdout -> stderr redirect in the
parallel execution case, so run-command can buffer/deinterlace output.

In the current design, this codepath is taken only in the parallel
execution case, since there is no polling/buffering for serialized
execution (it's real-time like before).

If you do not have any objection to the child_is_sending_output() name
or another suggestion, I will send v8 using it shortly with a comment
explaining why we're only polling the err fd.