[Lldb-commits] [lldb] [lldb-dap] Use existing lldb::IOObjectSP for DAP IO (NFC). (PR #128750)

[John Harrison via lldb-commits]

ashgti wrote:

 > To reliably force termination, I'd suggest changing the read thread to use a MainLoop object reading from the socket, and then terminating it via `loop.AddPendingCallback([&](MainLoopBase &loop) { loop.RequestTermination(); });`. It sounds a bit like overkill, but the main loop class is currently our multiplexing primitive with the widest platform support. It also goes along nicely with the IOObject classes you're introducing here. And when/if we have a way (see the Pipe patch) for it to handle pipes as well, we could have it handle stdout/err forwarding as well, and ditch the forwarding threads.

The one issue with this is that MainLoop on Windows only supports sockets, not Files. At the moment we primarily work over stdin/stdout for communication, although the `--connection` flag is in now, so we can support sockets.

> 
> (I can also imagine a setup where we reuse the top-level MainLoop object (the one that currently accepts connections). In this world the main thread would pull json data from (all) connections, and enqueue them to connection-specific request queues. The nice part about this approach is that there are fewer threads flying around, so it's easier to understand what's happening and easier to shut things down. The disadvantage is that the main thread becomes a bit of a choke point -- though I don't expect this to matter much in practice since we will usually only have one connection and I doubt that json (de)serialization is going to be the bottleneck)

I do think we could merge some of these threads if MainLoop supported Files on Windows. That may be worth tackling specifically to unblock this behavior.

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