Skip to content
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

Fix LSP status field missing randomly #1901

Merged
merged 4 commits into from
Nov 21, 2021
Merged

Fix LSP status field missing randomly #1901

merged 4 commits into from
Nov 21, 2021

Conversation

rchl
Copy link
Member

@rchl rchl commented Nov 20, 2021

The status fields for indicating that the server is running would sometimes not be shown. This has happened randomly when sessions were initializing.

The issue was that the view settings listener set up in DocumentViewListener would always trigger initially since we didn't initialize self._current_syntax from __init__ so the check if something has changed would evaluate to True and call self._reset().

At the point the self._reset() is called the SessionViews might already have been created (and in fact almost always are since the settings change is triggered by us adding new keys on starting the session) and the reset call will result in those being destroyed and new SessionViews created.

Now, this doesn't fix the root issue. I think the root issue is the fact that the SessionView.__del__ of those cleared instances can get called after the new SessionViews are created thus resulting in the old one erasing the view status set by the new one.

As nice as relying on __del__ might seem, I think it would be better to have explicit public methods for clearing the state and not relying on __del__ in general since it's not really guaranteed when those will run.

The fix ensures that we don't unnecessarily reset the sessions and trigger this issue on start.

@rchl
Copy link
Member Author

rchl commented Nov 20, 2021

Also added a fix for the root issue. Let me know if this should be included or separate.

@jwortmann this will potentially conflict with your task unfortunately.

@rchl
Copy link
Member Author

rchl commented Nov 20, 2021

Another advantage of being explicit is that we can enforce the cleanup to run on async thread.

Copy link
Member

@rwols rwols left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This adds more maintenance by asking everyone to remember to call cleanup code when refactoring stuff. On the other hand it's hard to ensure these destructors run from the right thread.

@rwols rwols merged commit 656b0c2 into main Nov 21, 2021
@rwols rwols deleted the fix/status-missing branch November 21, 2021 08:37
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants