https://github.com/clayborg commented:
So I added comments on fixes to the current implementation in inline comments. A few questions I have: - do we really want each progress to select if it should be coalesced as a `Progress` constructor arguments? Or do we want a global setting on how progress events should be delivered? - The current code adds a way to increment and decrement refcounts of ongoing progress categories (titles), but doesn't do anything with them, what do we envision happening with these ref counts? But overall I would think we would want to keep track of this at a higher layer than in this class. Like in the code that would be delivering the progress events. If we do it that way, then we could have a global setting that controls if users want events delivered by category or individually. We actually won't need a setting for this as we can just see who is listening to the process events. Anyone listening to `SBDebugger::eBroadcastBitProgress` would get progress events delivered on a one by one basis, and anyone listening to a new progress bit like `SBDebugger::eBroadcastBitProgressByCategory` would just get different events delivered and all of this ref counting by title code from here would be moved into Debugger.cpp where the other progress events are being handled already. https://github.com/llvm/llvm-project/pull/81026 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits