Re: [PATCH v7 10/12] run-command: poll child stdin in addition to stdout
- From
Adrian Ratiu <adrian.ratiu@collabora.com>
- Date
- Jan 27, 2026, 10:10 UTC
- Message-ID
- <87ecnbmkmi.fsf@gentoo.mail-host-address-is-not-set>
- In-Reply-To
- <xmqqms1zhq3s.fsf@gitster.g>
On Mon, 26 Jan 2026, Junio C Hamano <gitster@pobox.com> wrote:
Show 19 quoted lines
> Emily Shaffer <nasamuffin@google.com> 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.