Closed SethGower closed 1 year ago
Here is a good starting point https://github.com/VHDL-LS/rust_hdl/blob/master/vhdl_ls/src/stdio_server.rs#L171 if you want to make a PR
Thanks, I found that. I'll take a look later and maybe dig into it. Main reason I made the issue is just for transparency to make sure it was known so the PR isn't unexpected
I found that we had a masking of the Exit notification handling to return from the mainloop. But we also join the io threads there and I suspect they never exit. I now removed the mainloop return and forwarded the Exit notification to the server exit method which will call process::exit.
Could you try latest master and see if it is fixed?
I can confirm that this does not happen anymore in VSCode. I think issue can be closed.
@LukasVik I will take your word for it.
I have noticed that the Language server stays active even after the client has sent the shutdown command. This may be fine in the case of someone using an editor like VSCode, where you probably aren't starting and stopping the editor frequently. But it happens more with an editor like neovim. I have noticed that my RAM will slowly climb up over time, when I investigated it was because I had ~80 processes of
vhdl_ls
running, causing my system to be slow since all of my RAM (64GB) was being used. Once I killed all of the processes it fixed the issue. I have narrowed this down to VHDL LS since I have enabled debug logging in the client (nvim-lspconfig) and it sends the shutdown and exit commands. After these are sent, the PIDs are still active and using CPU time/RAM. Here's a basic output of the LSP Log for nvimUsing the basic test file
and the
vhdl_ls.toml
As you can see in the last few lines of the log it sends the shutdown and exit commands, however
vhdl_ls
doesn't actually exit. This can be compared to the shutdown process of another language server (sumneko-lua-language-server)