[Lldb-commits] [lldb] [lldb] Synchronize the debugger's stdout and stderr streams (PR #126630)
Pavel Labath via lldb-commits
lldb-commits at lists.llvm.org
Mon Feb 17 12:14:28 PST 2025
labath wrote:
The buffering doesn't sound like a problem to me. Basically it means you have to use the stream like an RAII object, which is sort of what we have here anyway. We also have the same problem with not being able to get everything to use the RAII locker object from this patch (due to legacy reasons..)
That said, not needing to replicate the locking logic in every IOHandler would definitely be nice.
However, I'm not certain about the feasibility of that. In a way, I think that the PrintAsync approach is better because it lets the IOHandler know that some async printing is happening, and it can choose how to deal with it. For example, the ProcessIOHandler (forwarding stdout of the debugger proces) can end up in a state where the debugged process has written only a half a line. If async printing is plumbed through it, it will know that is happening, and it can choose to do something about (print an extra newline to delimit process output, or maybe erase the last output line, and then redraw it after the async output -- I don't know).
I'm not a mind reader nor a time traveller, but I have a feeling this is the reason why the async functionality is implemented the way it is. Maybe that's something we don't need? I think I could live without it. But if that is the case, I would like to see it dismantled, at least partially. For example, do you think it would be possible to change Debugger::PrintAsync to print the output directly (after locking the stream and such) -- without going through the IOHandlers and stuff?
https://github.com/llvm/llvm-project/pull/126630
More information about the lldb-commits
mailing list