Re: [PATCHv3 02/11] run-command: report failure for degraded output just once

From: Junio C Hamano <gitster@pobox.com>
Date: Nov 4, 2015, 20:42 UTC
Message-ID: <xmqq8u6da448.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <CAGZ79kaiRKHd2RS9eNeZt_VZqqBF0HS0D=x1HbOTPXYOphu8pg@mail.gmail.com>

Stefan Beller <sbeller@google.com> writes:

Show 11 quoted lines

> Another approach would be to test if we can set to non blocking and if
> that is not possible, do not buffer it, but redirect the subcommand
> directly to stderr of the calling process.
>
>     if (set_nonblocking(pp->children[i].process.err) < 0) {
>         pp->children[i].process.err = 2;
>         degraded_parallelism = 1;
>     }
>
> and once we observe the degraded_parallelism flag, we can only
> schedule a maximum of one job at a time, having direct output?

I would even say that on a platform that is _capable_ of setting fd non-blocking, we should signal a grave error and die if an attempt to do so fails, period.

On the other hand, on a platform that is known to be incapable (e.g. lacks SETFL or NONBLOCK), we have two options.

1. If we can arrange to omit the intermediary buffer processing
   without butchering the flow of the main logic with many
   #ifdef..#endif, then that would make a lot of sense to do so, and
   running the processes in parallel with mixed output might be OK.
   It may not be very nice, but should be an acceptable compromise.

2. If we need to sprinkle conditional compilation all over the place
   to do so, then I do not think it is worth it.  Instead, we should
   keep a single code structure, and forbid setting numtasks to more
   than one, which would also remove the need for nonblock IO.

Either way, bringing "parallelism with sequential output" to platforms without nonblock IO can be left for a later day, when we find either (1) a good approach that does not require nonblock IO to do this, or (2) a good approach to do a nonblock IO on these platforms (we know about Windows, but there may be others; I dunno).