-
-
Notifications
You must be signed in to change notification settings - Fork 117
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
LSP Process can live on after quitting neovim #1599
Comments
lsp requires that the client first send a i notice that the in the worst case could just add an self-destruct timeout after |
it seems that nvim doesn't like to wait around, this PR reduces the grace period that Phpactor gives to it's services to shutdown: #1600 this improves the situation signficantly. but still a chance that phpactor won't respond in time (or the service takes longer and causes the nvim to get killed as with the previous issue we had), so probably also want to implement a self-destruct. |
Thank you, I try to update soon. My setup is a bit to complex right now for easy updates. Will let you know whether it solved the issue for me once I gave it a try. |
Maybe #1600 solves my similar problem for which I not found any time to describe and checking where it happens. |
Reducing the grace period causes other problems, we periodically need to check if we need to kill the |
Looks fine now. I still had stale processes after the first changes. The update to self destruct solved it. |
Not sure if this is an issue of phpactor or https://github.com/neovim/nvim-lspconfig/. I'm only using phpactor as LSP right now.
When I close a neovim instance which created an LSP Process, this process will still live. This can stack up to an huge number of processes after a week of work. I tend to close neovim instances and start from new when switching a concrete task within a project.
Would be cool if the LSP process is being killed as soon as the neovim process is killed.
Let me know if you need further info. Using neovim
and phpactor 45207d9 with php
7.4.29
The text was updated successfully, but these errors were encountered: