================
@@ -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
_______________________________________________
lldb-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
