clayborg wrote: > > 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? > > My understanding is that the constructor conveys whether something is an > "aggregate" progress event or not and they're broadcast differently so that > the listener can decide how they want to receive these "aggregate" events.
My idea is the user decides how to listen to the events by which `SBDebugger::eBroadcastBit` (`SBDebugger::eBroadcastBitProgress` or `SBDebugger::eBroadcastBitProgressByCategory`) they listen to, and we will deliver the events accordingly. > > > * 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? > > With the previous idea in mind, you need the refcount in case there are > overlapping events: > > ``` > eBroadcastBitProgress [foo] > eBroadcastBitProgress [foo] > eBroadcastBitProgressByCategory [foo ] > ---------------------------------------> (time) > ``` > > So basically if you have two events `foo` that overlap as shown above, if > you're listening for `eBroadcastBitProgress` you get two events. If you're > listening for `eBroadcastBitProgressByCategory`. The refcount is used to make > sure you don't broadcast an events for `eBroadcastBitProgressByCategory` when > the first foo ends. Yeah, with category, we will see "Indexing symbol table" and then we might have both "a.out" and "b.out" details from two different categories needing to be displayed. The debugger event that gets sent for `eBroadcastBitProgressByCategory` might need some new accessors to account for this. 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
