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

[Jonas Devlieghere via lldb-commits]

JDevlieghere wrote:

> Yesterday, I wasn't sure if we need the async stream mechanism. Today, I think we do (because of the prompt redrawing thingy). I think the two questions (async print and stream protection), but are separate in a way (the iohandlers still need, and the editline iohandler actually uses a mutex), but they are also kind of related in that they have to work together to achieve desired outcome ("nice" console output?) -- which may impact how they're implemented.

I think so too. When I started writing that message yesterday I was under the impression that we could get rid of the asynchronous streams altogether, but the prompt redrawing makes me doubt that. 

> At this point, I think the main question I am trying to answer is about a some guideline/rule about the usage of the various printing mechanism. Imagine I'm writing (or reviewing) a piece of code trying to print something. How do I know which method to use. If I can get a hold of a Debugger, I have the choice between GetOutputStreamSP, GetOutputFile and GetAsyncOutputStream. This patch doesn't really change that (which is why I think you say it's a net benefit), but it might make it seem like using GetOutputStreamSP (after locking it) is safe/okay -- which I think is the part that's bothering me.
>
> So to try to propose an answer to this question: would it be correct to say that (even after this patch, as it is right now), one should approximately always use GetAsyncOutputStream for printing stuff out (at least in cases where one doesn't have the CommandReturnObject around), and that the other methods exist as implementation details of that (supporting locking in iohandlers, which is necessary to produce output correctly), or due legacy code we don't know how to get rid of?

Yes. I now think that everyone should use the asynchronous streams by default. The lockable streams should only be used if the buffering poses a problem or you need the underlying stream for legacy reasons (e.g. the SB API). Let me try to confirm that assumption by converting all the uses that don't fall in the exception categories in a separate PR. If that works out, we can think about a way to enforce this at the API level (e.g. making the getters for the lockable stream private and relying on friends) and rebase this PR on top.  


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