JDevlieghere wrote: > Some thoughts: > > * The server could shut itself down if the process gets a low memory warning > and there are no active clients.
There is `SBDebugger::MemoryPressureDetected` that removes modules with a zero refcount. That might be a good API to wire up first. > * The server could have an idle timeout and shutdown if there are not active > clients after some configurable period. > * The extension could alert the user to unexpected crashes or exits. This sounds like a nice to have and I think should be fairly straightforward to hook up. > * The extension could have commands to manually start / stop the server. > * We could run one server per host instead of the default behavior of one > per-window. Its possible to spawn the server in a different process group > than the extension host process and advertise the connection parameters in a > different way (e.g. the server can use a unix socket and place the socket in > `~/.lldb-dap-sock` then if the socket file exists we could use it across > extension hosts). That's what Xcode does with the `lldb-rpc-server` and that's definitely going to be the most efficient, but also the most complicated to hook up. Thanks for putting this list together.I think all the options you mentioned make sense. > The main downside to the background server is the memory usage between debug > sessions. For example, having the server attach to an iOS application then > site between debug sessions results in a process consuming 1.3GB of memory > for my machine. Yup, we see the same thing with the lldb-rpc-server. I wonder how much calling `MemoryPressureDetected` would improve things. That said, we definitely have things that will only grow over time (like the ConstString pool). > At the moment though, I am keeping this relatively simple. 👍 https://github.com/llvm/llvm-project/pull/128957 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
