search

mesonbuild / vscode-meson

Meson for VisualStudio Code
Apache License 2.0
105 stars 50 forks source link

LSP runs two or more instances at once #171

Closed flobzex closed 10 months ago

flobzex commented 11 months ago

When VS Code is started or reloaded, the extension downloads and runs the LSP. However, it always starts at least two instances of Swift-MesonLSP. Besides, the processes are not cleaned when VS Code is closed or restarted, which results in various orphaned instances of the LSP running.

System info:

JCWasmx86 commented 11 months ago

Can confirm that. But for some reason it only happens with the installed extension, not if you open the vscode-meson repo in Codium and then want to debug it. this.ls.stop() here is async, so we should probably await it.

Furthermore I've seen that VSCode doesn't even send the shutdown/exit notifications to the server, so the issue is client-side

tristan957 commented 11 months ago

@JCWasmx86 can you submit a PR to make it await?

flobzex commented 11 months ago

I investigated a little. Apparently in src/extension.ts there must be a exports.deactivate function so that the extension can receive the termination callback. There's only the activate one there.

tristan957 commented 11 months ago

Thank you!

tristan957 commented 11 months ago

Are you interested in submitting a PR? Otherwise, I can look into it when I have time.

flobzex commented 11 months ago

I'm going to try creating a patch and will create a PR if it works (I'm not familiar with the codebase yet).

This would be my first contribution.

tristan957 commented 11 months ago

Works for me! Might try looking at what the clangd vscode extension does in its deactivate

flobzex commented 11 months ago

Good day, peeps! I've been testing ways to fix this bug and I found a few things.

Requesting the language server to terminate via the deactivate function works, but still, sometimes a new instance of the process is created. I suspect this behavior has to do with the current design, where the variable LanguageServerClient.ls is set to null after the LSP is stopped, and whenever the LSP needs to start, a new instance is created. That mixed with the concurrency of the async functions may be the cause the cause of this problem.

I'll keep on investigating this issue and see if I can find a fix.

Best regards

flobzex commented 10 months ago

Hello! I couldn't find a solution, but I found out that the problem is really in VSCode. It does call the dispose function, with or without the deactivate function, because LanguageClient is a disposable. The very source of the problem seems to be in this.ls.stop(), which succeeds, but the process doesn't get killed, even with await.

tristan957 commented 10 months ago

I haven't been able to reproduce this recently for what its worth. Someone else is probably gonna have to debug it.

Totto16 commented 10 months ago

I haven't been able to reproduce this recently for what its worth. Someone else is probably gonna have to debug it.

I can debug it, since at least #194 "works" (doesn't close) on my setup 🤔