royitaqi wrote: @JDevlieghere Thanks for the good questions. I appreciate all of them. Below are my thoughts for discussion.
> proliferation of new options > motivation Main motivation is memory pressure. Other ways to counter memory pressure is either to monitor from lldb-dap VS Code extension and SIGINT for lldb-dap process to stop, OR use "memory pressure detected" from within lldb-dap process but the timing is tricky. Side product is that the periodical restart will also clean up bad states that may happen. > command line option vs. over the protocol vs. VS Code settings IIUC, there are two aspects to it: lifetime, and where to live. The following is my thoughts but no strong opinion. Lifetime of the option: I feel this option is better for the lifetime of the lldb-dap process, because it should be consistent across different connections. Or maybe I'm missing a scenario where per-connection or per-target value works better. I think the above decides "where does the option live". If we decide that the option is better for the whole process, then I think we need both a command line argument and a VS Code setting. If it's going to be per connection, then we need a VS Code setting. > milliseconds Yeah I thought seconds/minutes will be more intuitive, too. FWIW, did a calculation, max int in milliseconds is about 24.8 days. I don't think anyone would want that long of a TTL, so the range seems big enough. But yeah, seconds/minutes would probably make more sense (who is gonna use <1s TTL, right?). > This definitely needs a test Yes, definitely (see "I will find a test file to add tests." in PR description). Yeah probably set TTL to be a 1 second and wait for it to terminate correctly within 3 seconds. https://github.com/llvm/llvm-project/pull/156803 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
