Since 2018 VSCode allows the supportsTerminateRequest feature which is described in detail here.
In a nutshell, if a debugger implementation (i.e. codelldb) supports a more graceful kill option, then opting-in to this capability will cause VSCode to send the terminate request rather than killing the process directly. This occurs the first time a user presses the stop button, but subsequent presses will perform the less graceful kill as an escape hatch. It seems the feature is fairly solidly implemented (this was added for Node.js debugger and when I've used it there it works great) the extension just needs to opt-in to receiving the signal and translate it appropriately (in our case probably issuing the LLDB command process signal SIGINT).
They even mention in the above article that this would be a good match for SIGINT.
On Unix-based operating systems, this could easily be achieved by sending the SIGINT signal to the debuggee.
Since an unbound SIGINT handler simply exits the app (which is equivalent to the present day behavior) this would probably be most appropriate to enable by default. That said, it would definitely be handy to have a config setting that lets the user select the signal they want to use (I personally use SIGINT and SIGTERM for slightly different thing and I could see some apps needing the SIGUSR signals too) or to disable it entirely (probably the same as mapping to SIGKILL?).
Since 2018 VSCode allows the
supportsTerminateRequestfeature which is described in detail here.In a nutshell, if a debugger implementation (i.e. codelldb) supports a more graceful kill option, then opting-in to this capability will cause VSCode to send the
terminaterequest rather than killing the process directly. This occurs the first time a user presses the stop button, but subsequent presses will perform the less graceful kill as an escape hatch. It seems the feature is fairly solidly implemented (this was added for Node.js debugger and when I've used it there it works great) the extension just needs to opt-in to receiving the signal and translate it appropriately (in our case probably issuing the LLDB commandprocess signal SIGINT).They even mention in the above article that this would be a good match for SIGINT.
Since an unbound SIGINT handler simply exits the app (which is equivalent to the present day behavior) this would probably be most appropriate to enable by default. That said, it would definitely be handy to have a config setting that lets the user select the signal they want to use (I personally use SIGINT and SIGTERM for slightly different thing and I could see some apps needing the SIGUSR signals too) or to disable it entirely (probably the same as mapping to SIGKILL?).