================
@@ -99,6 +105,10 @@ class Progress {
private:
void ReportProgress();
static std::atomic<uint64_t> g_id;
+ static std::atomic<uint64_t> g_refcount;
+ /// Map that tracks each progress object and if we've seen its start and stop
+ /// events
+ static std::unordered_map<std::string, uint64_t> g_map;
----------------
clayborg wrote:
> We spoke about this a little offline but at the moment although Progress
> reports hold on to debugger instances, these instances are null by default
> and most Progress reports don't give a debugger instance in their
> instantiation so we wouldn't be able to have a debugger instance hold on to
> their own map of ongoing progress reports.
>
> @clayborg Having a progress report holding on to a debugger instance is a
> good idea, but if we want to use a map to keep track of ongoing reports we
> need to know what will own the map? Do we want the map to be owned by a
> debugger instance or could the progress class hold on to its own map of
> ongoing reports? In the case of the former we would then want to enforce that
> progress reports have valid debugger instances and in the latter we could
> remove the `debugger` field from the reports altogether.
The main question is if we want all progress reports to follow the currently
selected mode (coalesce or individual) or if we want them to be able to pick
which one they are. I would vote to have a global setting that controls if we
deliver things, but would love to hear what others think.
Each Progress instance _can_ have a debugger, but most don't, and those will
get delivered to all debugger instances. So I would say that this map should
live in each debugger object because `Progress` objects _can_ have a debugger
set, and if they do, they will only get delivered to _that_ debugger.
So my suggestion here is to:
- not change anything in Progress.h/cpp
- move the progress categorization code into each debugger object
- in `PrivateReportProgress` we check if anyone is listening to the new
`eBroadcastBitProgressByCategory` bit, and then and _only_ then do we do any of
the category counting.
So the code in `PrivateReportProgress` will now look something like:
```
static void PrivateReportProgress(Debugger &debugger, uint64_t progress_id,
std::string title, std::string details,
uint64_t completed, uint64_t total,
bool is_debugger_specific) {
// Only deliver progress events if we have any progress listeners.
if
(debugger.GetBroadcaster().EventTypeHasListeners(Debugger::eBroadcastBitProgressByCategory))
PrivateReportProgressByCategory(debugger, progress_id,
is_debugger_specific, completed, total, is_debugger_specific);
const uint32_t event_type = Debugger::eBroadcastBitProgress;
if (!debugger.GetBroadcaster().EventTypeHasListeners(event_type))
return;
EventSP event_sp(new Event(
event_type,
new ProgressEventData(progress_id, std::move(title), std::move(details),
completed, total, is_debugger_specific)));
debugger.GetBroadcaster().BroadcastEvent(event_sp);
}
```
Then we write a new `PrivateReportProgressByCategory()` function that will do
all this book keeping and coordingate with the debugger which will own the
category ref count map
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
