[Lldb-commits] [lldb] [lldb] Synchronize the debugger's stdout and stderr streams (PR #126630)

[Jonas Devlieghere via lldb-commits]

JDevlieghere wrote:

> I guess so, but I think we're drawing different conclusions. My take on this is that if the only thing we get from locking stderr is the ability to mutually exclude two stderr accesses, then maybe we don't need to bother with locking stderr at all.

That's what I understood and I agree. We don't use the error stream all that much, so I don't feel strongly either way. If it were up to me I would've gone with doing it anyway for parity with stdout. 

> > > FWIW, there is some precedent for unconditional stdout-stderr interaction: writes to `std::cerr` will automatically flush `std::cout` regardless of whether the two streams refer to the same terminal. And the `iostream` library allows you to connect arbitrary two streams in this way. So, I think we _could_ say we "tie" debuggers output and error streams in this way, even if they are completely independent, because they are "our" stdout and stderr.
> > 
> > 
> > Fair enough. What I'm hearing is that you think it's important to synchronize the two somehow and I'd rather do it consistently rather than doing it only sometimes which makes it hard to know what the expectations both for us as the people writing that code and for our users.
> 
> Yes, I think that tying them _always_ is better than tying them _sometimes_. However, I don't really have a clear preference between the other options flying around. The options being:
> 
> * tying them always
> * not tying them at all
> * not tying them and not locking stderr
> 
> If it sounds like I'm in favor of one of them, it's because I'm comparing its (dis)advantages relative to some other approach. However, I think all of these approaches have their (dis)advantages.

Ack, I'm sorry if I was reading too much into it. Given that neither of us has a clear preference, and given that we need to make a decision, I'll suggest that we go with (1) as that's really the only thing that guarantees we don't mess up the statusline, which was the motivation behind this PR.  The other two options will probably still do the right thing most of the time so it's really about picking a tie-breaker.  

> > It should be fairly straightforward to support tying the two streams together. I'll see how that goes and update the PR.
> 
> A random idea, I don't know if it's a good one: have one object (LockableStreamPair?) that holds the two streams and their mutex. One less argument to pass around?

Sounds good, that simplifies the signatures (which this PR is already touching) and keeps the mutex abstracted away. 

https://github.com/llvm/llvm-project/pull/126630