jingham added a comment. In D120972#3370814 <https://reviews.llvm.org/D120972#3370814>, @clayborg wrote:
> In D120972#3370688 <https://reviews.llvm.org/D120972#3370688>, @jingham wrote: > >> In D120972#3370529 <https://reviews.llvm.org/D120972#3370529>, @clayborg >> wrote: >> >>> I liked that part of the patch where it wouldn't report events through the >>> debugger if someone is already handling them. lldb-vscode handles these >>> events already, but we also set the debugger's out and error file handle to >>> /dev/null >> >> This seems a little like the stop notification, where we don't emit that >> info when running under Xcode (or I presume vscode). In the case of the >> stop notification, we're gating that on the Debugger::GetAsyncOutput stream >> being set or not. In this case we're switching on whether the result of >> Debugger::GetOutputFile is interactive. In both cases, this seems more like >> something the client should turn on and off explicitly, on for the Driver, >> off for Xcode & VSCode? Doing it based on whether the terminal is >> interactive or has an async output channel seems a little indirect. > > This is only in the built in event loop, which lldb-vscode and Xcode do not > use, they run their own event loops. So the only thing we are left with is > the command line driver which uses this event loop. It's a little lower than just the event loop, since this gets done in Process::HandleProcessStateChangedEvent. That gets called in a small handful of places including Process::WaitForProcessToStop, which gets called from a bunch of other places. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D120972/new/ https://reviews.llvm.org/D120972 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
