ashgti wrote: > @ashgti Do you think we would adopt non-blocking I/O in `lldb-dap`? Since > we're using separate threads there, we can afford using long timeouts, but > maybe we'd like to use the main loop there too with non-blocking I/O. If not, > and if I were to implement the non-blocking support in MCP directly using > Pavel's snippet, would you want to move the `JSONTransport` back into > lldb-dap (and drop the JSON RPC variant) or keep it in Host?
lldb-dap today is most often used by communicating over stdin/stdout. When adding support for lldb-dap to have a server mode, the clients connect over a socket (unix or tcp). I wanted to be able to gracefully disconnect the clients if the server is interrupted. We don't strictly need to have non-blocking IO for lldb-dap to work in both cases, but it helps for the graceful disconnects. Right now, we sort of ignore the fact that the Transport never times out on Windows when running over stdin/stdout. In an ideal world we'd have uniform support for this, but from my understanding of Win32 and the APIs we're using, I wasn't able to figure out a solution for reading from stdin with a timeout. There are ways we could work around this, like always connecting over a socket on Windows instead of stdin/stdout but that would be a pretty big change and I'm not sure how many users there are of the lldb-dap binary on Windows that would be affected by the change. I can try to take another look at the Win32 APIs to see if there is an alternative because it would be nice if we had a uniform API surface for this. https://github.com/llvm/llvm-project/pull/144610 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
