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