labath added a comment. In D131837#3734204 <https://reviews.llvm.org/D131837#3734204>, @mgorny wrote:
> In D131837#3732971 <https://reviews.llvm.org/D131837#3732971>, @labath wrote: > >> This sort of makes sense to me, but it's not clear to me how is this >> selection logic going to apply to packets other than stop-replies. All of >> the forked processes are going to share the same pty, so it's going to be >> literally impossible to distinguish the `O` packets, for instance. I'm >> wondering if it would make sense to split this interface into two, and have >> just one "preferred" recipient of `O` packets (and possibly others as well >> -- as we have no plans for supporting them right now), and have a separate >> list of recipients who would do things with the stop replies? > > Specifically about the `O` packets, I've been thinking that it doesn't really > make any difference which process receives them — after all, they will be > printed all the same, won't they? Not exactly. That output gets routed through process-specific (SB)Process:GetSTDOUT functions. Of course, if you're using the command line, then all of these outputs will funnel into the lldb terminal anyway, but a scripting/gui user might be doing something different. I guess one of the goals of a future larger SB API redesign could be refactor this such that it is clear that forked processes will share the same terminal/stdout.. ================ Comment at: lldb/source/Plugins/Process/gdb-remote/GDBRemoteClientBase.h:23 virtual ~ContinueDelegate(); - virtual void HandleAsyncStdout(llvm::StringRef out) = 0; - virtual void HandleAsyncMisc(llvm::StringRef data) = 0; - virtual void HandleStopReply() = 0; + virtual void HandleAsyncStdout(llvm::StringRef out, bool &handled) = 0; + virtual void HandleAsyncMisc(llvm::StringRef data, bool &handled) = 0; ---------------- mgorny wrote: > labath wrote: > > Why not just make this a regular return value? > I've figured out an explicit variable makes its purpose clearer, rather than > arbitrary `return true/false`. Maybe sometimes, but I don't think that's the case here. I mean, if you think this is particularly ambiguous, you could make a `{handled, not_handled}` enum and return that. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D131837/new/ https://reviews.llvm.org/D131837 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
