Re: [PATCH 2/2] fetch: fetch submodules in parallel

From: Jeff King <peff@peff.net>
Date: Sep 14, 2015, 18:07 UTC
Message-ID: <20150914180759.GA11920@sigill.intra.peff.net>
In-Reply-To: <20150914175509.GJ8165@google.com>

On Mon, Sep 14, 2015 at 10:55:09AM -0700, Jonathan Nieder wrote:

Show 12 quoted lines

> > I don't think you need exact timing information.  This is no different
> > than running the commands themselves, with stdout and stderr writing to
> > a pty that your terminal emulator will then read() from. If the program
> > produces intermingled stdout/stderr that clogs up the terminal, that is
> > its problem.
> 
> The difference is that when stdout and stderr write to a pty, they write
> to the same pty.  That is, suppose a child process does
> 
> 	write(1, "A\n", 2);
> 	write(2, "B\n", 1);
> 	write(1, "C\n", 2);

Ah, right. The pty is where things get mixed, not the read() from the terminal. So it depends on the write() order. Thanks for the explanation.

Show 7 quoted lines

> One can imagine a "git grep --recurse-submodules" that wants to run a
> grep in each submodule and combine their output in some appropriate
> way.  It's not clear what order is best for that use case: stderr
> (errors, plus progress in some imaginary future) at the beginning to
> show the story of how output was generated before the output?  stderr
> at the end so errors are not hidden way up on the screen?  Some kind
> of interleaving that pays attention to the format of stdout?

I'd suggest a "best effort" interleaving, where we select and preserve the read() order. That makes the easy cases work (you get things in the original order), and the hard cases at least do something reasonable (we may reorder two items which come in the same atomic "tick" of our select, but at least they are nearby).

That's just my gut feeling, though.

> That is more complicated than the "fetch --recurse-submodules" case
> that Stefan is currently tackling, so it seems wise to me to punt for
> now.

I can live with that.

-Peff