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

From: Junio C Hamano <gitster@pobox.com>
Date: Nov 4, 2015, 21:19 UTC
Message-ID: <xmqqziyt8nth.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <CAGZ79kbwJrQ9SrGkJsSx9oUcP98dn9wP=ZvgQLRjmPaZtOzanA@mail.gmail.com>

Stefan Beller <sbeller@google.com> writes:

Show 6 quoted lines

> So more like:
>
>     if (platform_capable_non_blocking_IO())
>         set_nonblocking_or_die(&pp->children[i].process.err);
>     else
>         pp->children[i].process.err = 2; /* ugly intermixed output is possible*/

When I mentioned #if..#endif, I didn't mean it as a dogmatic "conditional compilation is wrong" sense. It was more about "the high-level flow of logic should not have to know too much about platform peculiarities". As platform_capable_non_blocking_IO() function would be a constant function after you compile it for a single platform, if you add 10 instances of such if/else in a patch that adds 250 lines, unless the change is to add a set of lowest level helpers to be called from the higher-level flow of logic so that the callers do not have to know about the platform details, that's just as bad as adding 10 instances of #if..#endif.

Show 11 quoted lines

>> 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.
>
> From what I hear this kind of output is very annoying. (One of the
> main complaints of repo users beside missing atomic fetch transactions)

When (1) "parallelism with sequential output" is the desired outcome, (2) on some platforms we haven't found a way to achieve both, and (3) a non-sequential output is unacceptable, then parallelism has to give :-(.

I was getting an impression from your "not buffer" suggestion that "sequential output" would be the one that can be sacrificed, but that is OK. Until we find a way to achieve both at the same time, achieving only either one or the other is better than achieving nothing.

Show 5 quoted lines

>> 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).