================
@@ -66,3 +66,47 @@ void Progress::ReportProgress() {
m_debugger_id);
}
}
+
+void ProgressManager::Initialize() {
+ lldbassert(!InstanceImpl() && "A progress report manager already exists.");
+ InstanceImpl().emplace();
+}
+
+void ProgressManager::Terminate() {
+ lldbassert(InstanceImpl() &&
+ "A progress report manager has already been terminated.");
+ InstanceImpl().reset();
+}
+
+std::optional<ProgressManager> &ProgressManager::InstanceImpl() {
+ static std::optional<ProgressManager> g_progress_manager;
+ return g_progress_manager;
+}
+
+ProgressManager::ProgressManager() : m_progress_map() {}
+
+ProgressManager::~ProgressManager() {}
+
+ProgressManager &ProgressManager::Instance() { return *InstanceImpl(); }
----------------
JDevlieghere wrote:
Yeah, I understand why we might want to leak the vector and do in other places.
But do you think we should just do that unconditionally, no matter whether it's
a problem or not? The other subsystems I mention use the same approach and they
don't crash in production even though they don't check the optional before
dereferencing it (treating it as a precondition).
I guess the point I'm trying to make is let's not leak it proactively, but use
the stricter approach to force a crash/assert in debug builds and tests, and
try to avoid these issues, rather than work around them. If we find that it
does end up crashing because someone emits a progress report when we're
shutting down LLDB **and** we've investigated the bug and think the
functionality is important, I'm totally on board with leaking it. Does that
sound like a reasonable compromise?
https://github.com/llvm/llvm-project/pull/81319
_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
