From: Adrian Ratiu Date: Tue, 27 Jan 2026 10:10:29 GMT Subject: Re: [PATCH v7 10/12] run-command: poll child stdin in addition to stdout Message-ID: <87ecnbmkmi.fsf@gentoo.mail-host-address-is-not-set> In-Reply-To: On Mon, 26 Jan 2026, Junio C Hamano wrote: > Emily Shaffer 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.