================
@@ -150,12 +153,17 @@ static void
client_handle(GDBRemoteCommunicationServerPlatform &platform,
printf("Disconnected.\n");
}
-static GDBRemoteCommunicationServerPlatform::PortMap gdbserver_portmap;
-static std::mutex gdbserver_portmap_mutex;
-
static void spawn_process_reaped(lldb::pid_t pid, int signal, int status) {
- std::lock_guard<std::mutex> guard(gdbserver_portmap_mutex);
- gdbserver_portmap.FreePortForProcess(pid);
+ if (g_single_pid != LLDB_INVALID_PROCESS_ID && g_single_pid == pid) {
+ // If not running as a server and the platform connection is closed
+ if (!g_terminate) {
+ g_terminate = true;
----------------
labath wrote:
I'm not particularly happy with the design of this callback, but that doesn't
mean it can't be used safely. The "uncontrollable" aspect means it is up to you
(its user) to ensure the callback does not access any arguments after they are
destroyed. It doesn't matter if they're local or global or how they're passed
into the callback. The new implementation is better (because it's easier to
reason about), but it still accesses the global main loop object, which will
get destroyed some time after `main` returns. So, the question here is "is
there anything ensuring that does not happen?" and not "is mainloop a global?".
If there is (for example, because the main thread waits for the callback to
call `RequestTermination()`), then I'm pretty this could be refactored to avoid
the global. If there isn't, then this is a problem even though the variable is
global.
https://github.com/llvm/llvm-project/pull/104238
_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
