[Lldb-commits] [lldb] [lldb] Multithreading lldb-server works on Windows now; fixed gdb port mapping (PR #100670)

[Dmitry Vasilyev via lldb-commits]

================
@@ -324,6 +324,18 @@ Status PipePosix::ReadWithTimeout(void *buf, size_t size,
         bytes_read += result;
         if (bytes_read == size || result == 0)
           break;
+
+        // This is the workaround for the following bug in Linux multithreading
+        // select() https://bugzilla.kernel.org/show_bug.cgi?id=546
+        // ReadWithTimeout() with a non-zero timeout is used only to
+        // read the port number from the gdbserver pipe
+        // in GDBRemoteCommunication::StartDebugserverProcess().
+        // The port number may be "1024\0".."65535\0".
+        if (timeout.count() > 0 && size == 6 && bytes_read == 5 &&
+            static_cast<char *>(buf)[4] == '\0') {
+          break;
+        }
----------------
slydiman wrote:

I don't think so. Note select() works fine with the pipe closed on other side in the single thread. select() hangs in case of simultaneously calls from few threads. I tried to connect to `lldb-server platform` and launch `lldb-server gdbserver` in few threads. It works 50/50 in case of 2 threads and 100% failed in case of 3+ threads. Instead of using select() I tried
- use poll()
- use read(size = 0)
- use non blocked pipe and call read() w/o select() or poll()
- change pipe buffer size
Nothing helped. It is the bug in the kernel. read() will hang too if the pipe is closed on the other side. Non blocking read() will return EAGAIN instead of 0. The system just does not recognize the closed pipe in case of multithreading.
So, I don't see a way to fix this on Linux. The only way is a workaround.

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