JDevlieghere wrote:
I tried implementing this and waiting on the thread pool when the last debugger
is being destroyed is easy:
```
// Only hold the debugger list lock long enough to check if we're the last
// debugger being destroyed.
bool last_debugger_being_destroyed = false;
if (g_debugger_list_ptr && g_debugger_list_mutex_ptr) {
std::lock_guard<std::recursive_mutex> guard(*g_debugger_list_mutex_ptr);
last_debugger_being_destroyed =
g_debugger_list_ptr->size() == 1 &&
(*g_debugger_list_ptr)[0].get() == debugger_sp.get();
}
// Check if we should wait on the thread pool. If the debugger being destroyed
// is the very last one, we can safely assume work is being done on its
// behalf. We want to keep the debugger alive at least until the background
// tasks are finished so they can report their progress.
if (last_debugger_being_destroyed)
g_thread_pool->wait();
```
However, at that point there's no default event handler thread anymore: we tear
it down when exiting `RunCommandInterpreter`. I think I'm just going to move
the timeout to the driver and call it a day...
https://github.com/llvm/llvm-project/pull/82799
_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
