-
Notifications
You must be signed in to change notification settings - Fork 22
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
This commit builds on the changes introduced to the `SubprocessSphinxClient` to greatly simplify and improve the robustness of managing the set of `SphinxClients` in use by the language server. There were a few drawbacks to the previous approach - While await on the `_client_creating` task during client creation appeared to work, it still often led to the creation of duplicated clients. - By not recognizing when a given configuration was broken, the manager would continually attempt to spawn client instances. - It was not uncommon to enter an infinite loop of spawning clients! The new system introduced in this commit *shouldn't* suffer from any of the above issues. - Instead of indexing clients by `src_uri`, they are instead indexed by the scope of the configuration governing the instance. While still not perfect, we should be able to accurately determine the relevant client for a given uri in more scenarios. - To indicate that we are unable to create a client for a given config we now store a `None` in the clients dictionary - preventing any further attempts at spawning a client. - Taking advantage of the fact clients are indexed by scope and that the client itself is `await`-able, we can have multiple consumers of the client awaiting on the client - preventing the issue of duplicated clients. Currently, there is a quirk to the system where the first batch of callers to `get_client` in a given scope will be told there is no client. However, they have in fact "primed" the system by creating a config subscription which will asynchronously populate the `clients` dict with an unstarted client. The next batch of callers will then discover that there is a client instance available and `await` it, starting the underlying Sphinx process. Based on some initial testing this "quirk" may actually be desirable, the `get_client` method is called often enough that I wasn't able to notice a real delay in starting the Sphinx process up. It also has the nice property that when restarting the server with multiple projects open, the flood of `didOpen` notifications from the client is enough to "prime" the system for each project, but the project itself is only activated when working on the relevant file in the editor. One final note, there are plenty of improvements still to be made - error handling, config changes etc, but hopefully this is a solid base we can start building on.
- Loading branch information
Showing
3 changed files
with
284 additions
and
160 deletions.
There are no files selected for viewing
This file contains 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
This file contains 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
Oops, something went wrong.