On Wed, Nov 4, 2015 at 10:14 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote:
> Stefan Beller <sbeller@xxxxxxxxxx> writes:
>
>> The warning message is cluttering the output itself,
>> so just report it once.
>>
>> Signed-off-by: Stefan Beller <sbeller@xxxxxxxxxx>
>> ---
>> run-command.c | 20 ++++++++++++++------
>> 1 file changed, 14 insertions(+), 6 deletions(-)
>>
>> diff --git a/run-command.c b/run-command.c
>> index 7c00c21..3ae563f 100644
>> --- a/run-command.c
>> +++ b/run-command.c
>> @@ -1012,13 +1012,21 @@ static void pp_cleanup(struct parallel_processes *pp)
>>
>> static void set_nonblocking(int fd)
>> {
>> + static int reported_degrade = 0;
>> int flags = fcntl(fd, F_GETFL);
>> - if (flags < 0)
>> - warning("Could not get file status flags, "
>> - "output will be degraded");
>> - else if (fcntl(fd, F_SETFL, flags | O_NONBLOCK))
>> - warning("Could not set file status flags, "
>> - "output will be degraded");
>> + if (flags < 0) {
>> + if (!reported_degrade) {
>> + warning("Could not get file status flags, "
>> + "output will be degraded");
>> + reported_degrade = 1;
>> + }
>> + } else if (fcntl(fd, F_SETFL, flags | O_NONBLOCK)) {
>> + if (!reported_degrade) {
>> + warning("Could not set file status flags, "
>> + "output will be degraded");
>> + reported_degrade = 1;
>> + }
>> + }
>> }
>
> Imagine that we are running two things A and B at the same time. We
> ask poll(2) and it says both A and B have some data ready to be
> read, and we try to read from A. strbuf_read_once() would try to
> read up to 8K, relying on the fact that you earlier set the IO to be
> nonblock. It will get stuck reading from A without allowing output
> from B to drain. B's write may get stuck because we are not reading
> from it, and would cause B to stop making progress.
>
> What if the other sides of the connection from A and B are talking
> with each other,
I am not sure if we want to allow this ever. How would that work with
jobs==1? How do we guarantee to have A and B running at the same time?
In a later version of the parallel processing we may have some other ramping
up mechanisms, such as: "First run only one process until it outputted at least
250 bytes", which would also produce such a lock. So instead a time based ramp
up may be better. But my general concern is how much guarantees are we selling
here? Maybe the documentation needs to explicitly state that we cannot talk to
each or at least should assume the blocking of stdout/err.
> and B's non-progress caused the processing for A on
> the other side of the connection to block, causing it not to produce
> more output to allow us to make progress reading from A (so that
> eventually we can give B a chance to drain its output)? Imagine A
> and B are pushes to the same remote, B may be pushing a change to a
> submodule while A may be pushing a matching change to its
> superproject, and the server may be trying to make sure that the
> submodule update completes and updates the ref before making the
> superproject's tree that binds that updated submodule's commit
> availble, for example? Can we make any progress from that point?
>
> I am not convinced that the failure to set nonblock IO is merely
> "output will be degraded". It feels more like a fatal error if we
> are driving more than one task at the same time.
>
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?
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html