Terminate pending background indexing and preparation tasks when shutting down SourceKit-LSP #2081
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
ahoppen
force-pushed
the
cancel-in-progress-indexing
branch
from
b92e2df to
c22dc37
Compare
|
@swift-ci Please test |
1 similar comment
|
@swift-ci Please test |
ahoppen
force-pushed
the
cancel-in-progress-indexing
branch
from
c22dc37 to
2307807
Compare
|
@swift-ci Please test |
|
@swift-ci Please test Windows |
|
@swift-ci Please test Linux |
bnbarham
approved these changes
Mar 22, 2025
|
@swift-ci Please test Linux |
ahoppen
force-pushed
the
cancel-in-progress-indexing
branch
from
2307807 to
77da5fd
Compare
|
@swift-ci Please test |
|
@swift-ci Please test Windows |
ahoppen
force-pushed
the
cancel-in-progress-indexing
branch
from
77da5fd to
3367496
Compare
|
@swift-ci Please test |
|
@swift-ci Please test Windows |
…ting down SourceKit-LSP When SourceKit-LSP is shut down, we should make sure that we don’t leave behind child processes, which will become orphans after SourceKit-LSP has terminated. What’s worse, when SourceKit-LSP has exited, these processes might not have any process to read their stdout/stderr, which can lead to them running indefinitely. This change does not cover the termination of subprocess trees. For example, if we launch `swift build` and need to kill it because it doesn’t honor SIGINT, its child processes will still live on. Similarly, if we kill a BSP server, its child processes might live on. Fixing this is a drastically bigger endeavor, likely requiring changes to Foundation and/or TSC. I filed swiftlang#2080 for it.
ahoppen
force-pushed
the
cancel-in-progress-indexing
branch
from
3367496 to
3bb4690
Compare
|
@swift-ci Please test |
|
@swift-ci Please test Windows |
|
@swift-ci Please test macOS |
ahoppen
added a commit
to ahoppen/sourcekit-lsp
that referenced
this pull request
May 13, 2025
…down This is what `shutDown()` is documented to do. I also remember having this check before, it might have gotten lost during a rebase when I was working on swiftlang#2081. I noticed this while investigating swiftlang#2152: In this case `buildTarget/prepare` was cancelled because the SourceKit-LSP server was shut down but indexing of a file was still started after the shutdown now that preparation had finished (because it was cancelled).
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
When SourceKit-LSP is shut down, we should make sure that we don’t leave behind child processes, which will become orphans after SourceKit-LSP has terminated. What’s worse, when SourceKit-LSP has exited, these processes might not have any process to read their stdout/stderr, which can lead to them running indefinitely.
This change does not cover the termination of subprocess trees. For example, if we launch
swift buildand need to kill it because it doesn’t honor SIGINT, its child processes will still live on. Similarly, if we kill a BSP server, its child processes might live on. Fixing this is a drastically bigger endeavor, likely requiring changes to Foundation and/or TSC. I filed #2080 for it.