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

[Pavel Labath via lldb-commits]

================
@@ -601,15 +570,24 @@ int main_platform(int argc, char *argv[]) {
       // If not running as a server, this process will not accept
       // connections while a connection is active.
       acceptor_up.reset();
-
-      // When not running in server mode, use all available ports
-      platform.SetPortMap(std::move(gdbserver_portmap));
     }
 
     platform.SetConnection(std::unique_ptr<Connection>(conn));
     client_handle(platform, inferior_arguments);
   } while (g_server);
 
+  // FIXME: Make TCPSocket::CloseListenSockets() public and implement
+  // Acceptor::Close().
+  /*
+  if (acceptor_gdb && gdb_thread.IsJoinable()) {
+    g_listen_gdb = false;
+    static_cast<TCPSocket *>(acceptor_gdb->m_listener_socket_up.get())
+        ->CloseListenSockets();
+    lldb::thread_result_t result;
+    gdb_thread.Join(&result);
+  }
+  */
+
----------------
labath wrote:

<rant>It's not just linux, that kind of pattern is racy on all posix operating systems. It's possible that other OSs will not hang in this situation, but that doesn't mean that usage is safe. Even on windows, that can cause you to call (WSA)accept on a dangling socket descriptor -- since you can never be sure whether the other thread has already called the function, or is it merely about to do that. It's less likely to blow up in your face because windows does not recycle FDs like posix systems do, but I wouldn't recommend that anywhere.</rant>

Exiting the main thread may be convenient, but I definitely wouldn't call it "safe", as that means the other thread may be running, executing random code and memory, while the main thread is shutting everything down and deleting that memory. It may not matter often, as the process is done anyway, but if anyone was observing the exit code, he may be suprised to see a SEGV instead of a clean exit.

Reasoning about a singlethreaded application is much easier than for a multithreaded one. We should already have all of the pieces to do this the right way, so let's just do that.

https://github.com/llvm/llvm-project/pull/104238