Avoid hiding output due only to parallelism

[rrnewton]

In a mailing list post, it was mentioned that stack test hides output from parallel tests to prevent interleaving.

Indeed, this was the traditional behavior of cabal -- to link parallelism to output verbosity. But this always annoyed me; rather, I argue that these are orthogonal configuration options that should be controlled by separate flags. In particular there are good ways to handle the concurrent output that do not require ugly interleaving.

1. gather output from parallel sub-tasks but stream it to stdout in the order that the sequential execution would have (deterministic)
2. allow nondeterminism in overall ordering, but only pass through output from subtasks that have completed.
3. monitor output in real time and elect the sub-task with either the highest rate of ongoing output, or the highest likelyhood of completion to hold stdout. The semantics of this are the same as option (2), but the perceived latency should be lower, as there is always some sub-task holding onto stdout.
4. interleave output but prefix it with some identifying [tag], and possibly buffer it for a second or more so that it gets grouped into "chunks" rather than interleaved lines or characters. This option offers an upper-bound on delay to any individual output line.
5. (whimsical) split the screen as many times as necessary to show the concurrent output. This is a fun way to visualize the degree of parallelism, and I played around with this in a little library called hydra-print based on the io-streams package.

I see that stack already depends on conduit. This seems like the kind of issue that could be solved generally, once and for all, at the conduit level. But, that presumes that stdout/stderr are captured and routed in all the right places.

I haven't read much of the code, but having a look at Execute.hs, it looks like the notion of parallel actions includes exception handling but not output streams.

On the other hand, Read.hs contains machinery for capturing output of sub-processes, and try/readProcessStdout are called in various places. But actions like running tests are handled by the underlying Cabal library, right? Does that mean their output can't be managed easily without changing Cabal?

Anyway, if a capability for generally handling output stream muxing/demuxing would be a desired feature I'd like to lend a hand with this.

[snoyberg]

I think this is the same as #426 (which, strangely enough, has the same digits as this issue number). Can you confirm that that's the same goal as what you have here?

[rrnewton]

Ah, yes! Same goal. Interesting though how many different policies/algorithms there are in this area.

You weren't happy with the algorithm described on #426. Do you have a preferred option of those above. Perhaps (4)?

[snoyberg]

It's not so much the algorithm as the complexity in implementation. I think it's fair to say that I'm just concerned about introducing lots of code, especially code that has the potential to exhaust memory with log output. For me personally, this outweighs the benefits of putting all output on the console, but I can understand others feeling differently.

If you're OK with it: let's close out this issue and continue the conversation on #426. If it's not too disruptive to the codebase and can be turned on and off, I'll be OK with most implementation approaches.

[snoyberg]

Relevant PR: #4097