[Lldb-commits] [lldb] [lldb] Removed gdbserver ports map from lldb-server (PR #104238)

[Pavel Labath via lldb-commits]

================
@@ -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