Use asyncio by rwols · Pull Request #2880 · sublimelsp/LSP

rwols · 2026-04-22T17:34:21Z

This is for now a draft PR where I'm trying to introduce asyncio and replace callback-based code with async functions. I'll keep a todo list here for the things that I believe need to be done before marking this work as ready for review. You are free to comment, make suggestions, and dispute, during the draft of course. Lots of functionality does not work at all at the moment of opening this work as draft.

The main driver for doing this is to decrease the thread usage of this plugin from O(n) to O(1) threads, where n is the number of language servers running. The secondary driver is syntax sugar.

Topic	Old Way	New Way
Running a short function on a thread that's not the main thread	`sublime.set_timeout_async`	`sublime_aio.call_soon_threadsafe`
Defining a function that's asynchronous	`def f() -> Promise[T]: ...`	`async def f() -> T: ...`
Chaining asynchronous functions	`Promise.then(lambda x: ...)`	`x = await f()`
Doing something when a server request is done	`session.send_request_async(R(), lambda x: ...)`	`x = await session.request(R())`
Doing something when a server request fails	define an on_error callback	use a `try ... except ResponseException:` block
Handling partial request results	define an on_partial_result callback	`async for partial_result in session.stream(R()):` (caveat: only works for `list[...]`-style responses)
Starting a coroutine from a regular function	n/a	`sublime_aio.run_coroutine(f())`
Awaiting old-style `Promise` objects	`Promise.then`	`await promise`
Waiting for all asynchronous operations to complete	`Promise.all`	`asyncio.gather`
Doing something later	`sublime.set_timeout_async(f, timeout_ms=1000)`	`await asyncio.sleep(1)`
Enforcing a critical section	use `threading.Lock`, or write very complicated queueing logic	use `asyncio.Lock`
Sending server requests (details)	use a concurrent send queue	use `sublime_aio.run_coroutine`

The Plan

Make "most" code run on the sublime_aio thread

Most code is doing bookkeeping. This type of code used to run on the Sublime "async" thread. It should run on the asyncio loop thread.

Previously, the code attempted to make most code run on the ST async thread. We never really enforced this. We tried to make it clear that a function/method should be running on the ST async thread by suffixing it with _async.

If you have an async def coroutine function, then such a coroutine function is forced to run on the asyncio loop thread. So enforcement becomes automatic.

Make compute-intensive function run on the Sublime "async" thread

The only compute-intensive code we deal with are parsing and emitting JSON. Only the JSON parser/emitter should run on the ST async thread.

Bridging code for existing LSP-* plugins

We made sure that all AbstractPlugin and LspPlugin related (class)methods ran on the ST async thread. I want to now make sure all these (class)methods run on the sublime_aio thread with this pull request.

Certain methods may also be marked async for LspPlugin, most notably on_pre_start and perhaps on_initialize.

The Promise object can be awaited, so older AbstractPlugin/LspPlugin-related functionality returning promises from request handlers should work (although currently untested).

TODO: work this out futher (there's a Promise.__await__ defined, so at least we can await promises)

Add a test that checks that "tcp server mode" works. Server meaning that this plugin acts as the TCP server and the langserver connects as TCP client.

Conflicts: tests/server.py

netlify · 2026-04-22T17:34:36Z

✅ Deploy Preview for sublime-lsp ready!

Name	Link
🔨 Latest commit	`ea34714`
🔍 Latest deploy log	https://app.netlify.com/projects/sublime-lsp/deploys/69f67744a38ae900085b6b8d
😎 Deploy Preview	https://deploy-preview-2880--sublime-lsp.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to your Netlify project configuration.

…se later

rwols · 2026-04-22T20:08:00Z

It's okay if #2739 is merged before this. I'll take care of the merge conflicts.

Also write the rest of the requests in terms of Session.request

rchl · 2026-04-22T20:42:39Z

Would be useful to split it into smaller chunks, if possible. For example it would likely be possible to make start_async async by making it return a Promise and then later convert it to asyncio easily.

Lots of assumptions on my side but that's what I feel.

I was actually looking into that before as I wanted to move start_async into dedicated thread so that it doesn't black other plugins (kinda opposite goal of yours but also kinda similar as I guess with asyncio it will also run on dedicated thread). See #2863

It will be hard to review it properly with a big dump of code that refactors most of the code base.

jwortmann · 2026-04-22T22:35:31Z

-                    self._new_session = None
-                    sublime.set_timeout_async(self._dequeue_listener_async)
-                    self._window.status_message(message)
+    async def start(self, config: ClientConfig, listener: AbstractViewListener) -> None:


Not sure if relevant, and my understanding of asyncio is also poor at the moment, but not too long ago I added a lsp_check_applicable command that can be used by plugins to start/stop the session (or attach/detach) for a given view (used by LSP-copilot on changes to .copilotignore file):

LSP/plugin/core/registry.py

Lines 258 to 262 in 59c9d86

wm.start_async(config, self.view)

if wm._new_session:

wm._sessions.add(wm._new_session)

listener.on_session_initialized_async(wm._new_session)

wm._new_session = None

This uses start_async and also a few additional lines that were required to start a new session properly.

That code probably needs to be adapted to this rewrite as well.

Note that this code will likely change (#2893).

- Add sublime.set_timeout executor wrapper - Make all request handlers `async` - Define a CancellableInflightStreamingRequest class that enables `async for` syntax - Start inheriting DocumentSyncListener from sublime_aio.ViewEventListener (This one doesn't work yet) The state is fairly broken at this point.

rchl · 2026-05-03T11:08:12Z

-            self._on_sheet_opened(view.sheet(), uri, r).then(resolve)
+            sheet = view.sheet()
+            if sheet and (view := sheet.view()):
+                view.settings().set('lsp_uri', uri)  # Preserve original URI given by the language server
+                if r:
+                    center_selection(view, r)
+                return view
+            return None


Probably wrong conflict resolution?

Sorry, could you point out what’s wrong? I remember spending time on this exact conflict and thinking this was the right resolution. But I’ve been wrong many times in the past.

It's not calling _on_sheet_opened anymore. The logic was moved there.

rchl · 2026-05-03T11:17:00Z

+        self.workspace_diagnostics_pending_responses[identifier] = inflight_request = self.request(
+            Request.workspaceDiagnostic(params),
+            partial_results=True
        )
+        try:
+            async for partial_response in inflight_request:
+                for diagnostic_report in partial_response['items']:
+                    uri = normalize_uri(diagnostic_report['uri'])
+                    version = diagnostic_report['version']
+                    # Skip if outdated
+                    if isinstance(version, int) and (session_buffer := self.get_session_buffer_for_uri(uri)) and \
+                            version < session_buffer.last_synced_version:
+                        continue
+                    self.diagnostics_result_ids[(uri, identifier)] = diagnostic_report.get('resultId')
+                    if is_workspace_full_document_diagnostic_report(diagnostic_report):
+                        self.handle_diagnostics(uri, identifier, version, diagnostic_report['items'])
+            await inflight_request
+            self.workspace_diagnostics_pending_responses[identifier] = None
+        except ResponseException as e:
+            if e.error['code'] == LSPErrorCodes.ServerCancelled:
+                data = e.error.get('data')
+                if is_diagnostic_server_cancellation_data(data) and data['retriggerRequest']:
+                    # Retrigger the request after a short delay, but don't reset the pending response variable for this
+                    # moment, to prevent new requests of this type in the meanwhile. The delay is used in order to prevent
+                    # infinite cycles of cancel -> retrigger, in case the server is busy.
+                    sublime.set_timeout_async(
+                        lambda: self._do_workspace_diagnostics_async(identifier),
+                        WORKSPACE_DIAGNOSTICS_RETRIGGER_DELAY
+                    )


Do we need to create such specific code to handle partial result?

The original logic seemed so much simpler, we just provide a handler for partial result and server either uses it or not.

With this new approach we need to create quite a bit different handler if partial result is possible and in practice it's possible in many more cases (that we currently don't handle).

Is it not possible to provide a callback for handling results (basically like before) but also await the request? Would awaited request block the thread or it would work fine to hang there for potentially a long time?

Good questions. This code, handling diagnostics, is currently broken. I'm still working out the details for partial results.

The latest iteration on this is the CancellableInflightStreamingRequest class I wrote in core/sessions.py for partial results. It is returned from a new Session.stream request:

async for partial_result in session.stream(Request("foobar")): # do something with partial_result

The (broken) code that you highlighted here also does a final await inflight_request, but I thought that was not intuitive. For partial requests, only a single async for loop should be necessary.

The original logic seemed so much simpler, we just provide a handler for partial result and server either uses it or not.

I don't agree, respectfully. Having the logic split over various callback functions is a worse experience than having the logic be in a single function.

However, setting a on_partial_result will still be needed for server requests that do not stream their partial results in a list[R] fashion. The fact that the final partial result will be an empty response list allows the async for logic to detect when to end the loop. Moreover I plan to just keep the on_partial_result callback logic available.

rchl · 2026-05-03T11:27:58Z

-                message = self._reader.readline().decode("utf-8", "replace")
-                if not message:
-                    continue
+                raw = await self._reader.readline()
+                if not raw:
+                    break


Why break instead of continue?

This code is pretty well battle-tested so changing the logic can be quite risky.

I tend to agree with you here. And I’ll try to revert this. But, my experience was: using continue here caused 100% CPU usage, suggesting an infinite loop. I’ll reconsider this.

rchl · 2026-05-03T11:32:26Z

+async def parse_headers(reader: asyncio.StreamReader) -> dict[str, str] | None:
+    headers: dict[str, str] = {}
+    while True:
+        line = await reader.readline()
+        if not line:
+            return None
+        line = line.decode("ascii").strip()
+        if not line:
+            break
+        key, value = line.split(":", 1)
+        headers[key.strip().lower()] = value.strip()
+    return headers


Can we not use http.client.parse_headers still? I feel that this implementation might be a bit naive compared to the original one.

Unfortunately no. There is no equivalent in asyncio. But JSON-RPC is simpler than HTTP anyway. There is only the Content-Length header from what I know. I do agree this manual header parser is less ideal than something from the stdlib.

rchl · 2026-05-03T11:45:11Z

+from ..protocol import ConfigurationItem
+from ..protocol import DocumentUri
+from ..protocol import ExecuteCommandParams
 from ..protocol import LSPAny
 from .core.constants import ST_STORAGE_PATH
 from .core.logging import exception_log
+from .core.logging import debug
+from .core.protocol import Notification
+from .core.protocol import Request


All of those additions can be removed (debug unused, the rest duplicated)

… resolving

rchl · 2026-05-03T15:06:53Z

An idea: keep original method names with _async suffix while working on the task and only rename in a dedicated PR after asyncio is actually merged.

Why? Because renaming introduces a significant amount of changes which means:

higher chance of conflicts with ongoing changes and more work resolving conflicts
a lot more (distracting) changes to go through when reviewing

rwols · 2026-05-03T15:20:00Z

Agreed, removing async suffices (suffixes?) was a mistake, I’ll revert that.

rwols added 13 commits April 13, 2026 23:50

Test both TCP modes

699dad3

Add a test that checks that "tcp server mode" works. Server meaning that this plugin acts as the TCP server and the langserver connects as TCP client.

Use enum for 'Mode' in server.py

908c849

Make init_options optional

b4f0420

WIP add asyncio to transports

76f3c3f

Test both TCP modes

45d7ea6

Add a test that checks that "tcp server mode" works. Server meaning that this plugin acts as the TCP server and the langserver connects as TCP client.

Use enum for 'Mode' in server.py

e8fae30

Make init_options optional

c511cec

Use StrEnum

7438d4a

Merge branch 'chore/add-tests' into feat/asyncio

6a104b0

More work on adding asyncio

d59bb1c

Merge branch 'main' into feat/asyncio

c0bea09

Conflicts: tests/server.py

More work towards asyncio

c1fc59c

Remove accidental merge conflict changes

e35b611

predragnikolic reviewed Apr 22, 2026

View reviewed changes

Comment thread tests/server.py Outdated

This comment was marked as resolved.

Sign in to view

rwols added 3 commits April 22, 2026 20:17

Remove code in server.py, I really screwed up the merge but will reba…

6cad098

…se later

refactor Promise.__await__

1597782

Add more comments to _SetTimeoutAsyncExecutor

cc642f4

Rename Session._invoke_views -> Session._invoke_views_async

cea0e99

Also write the rest of the requests in terms of Session.request

rchl reviewed Apr 22, 2026

View reviewed changes

Comment thread plugin/core/promise.py Outdated

jwortmann reviewed Apr 22, 2026

View reviewed changes

rchl reviewed Apr 22, 2026

View reviewed changes

Comment thread plugin/core/windows.py

rwols added 5 commits April 28, 2026 18:53

debugging sublime_aio.ViewEventListener

472705b

Merge branch 'main' into feat/asyncio

ea34714

Fix calls

069ed50

More fix calls

776749a

rchl reviewed May 3, 2026

View reviewed changes

rwols added 2 commits May 3, 2026 16:45

More work. Some diagnostics show intermittently. Request logic is not…

0227877

… resolving

Tweaks to pull diagnostics handling

2649a6f

rwols force-pushed the feat/asyncio branch 2 times, most recently from d716ebb to 2649a6f Compare May 4, 2026 17:14

	wm.start_async(config, self.view)
	if wm._new_session:
	wm._sessions.add(wm._new_session)
	listener.on_session_initialized_async(wm._new_session)
	wm._new_session = None

Conversation

rwols commented Apr 22, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

The Plan

Make "most" code run on the sublime_aio thread

Make compute-intensive function run on the Sublime "async" thread

Bridging code for existing LSP-* plugins

Uh oh!

netlify Bot commented Apr 22, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

✅ Deploy Preview for sublime-lsp ready!

Uh oh!

Uh oh!

This comment was marked as resolved.

rwols commented Apr 22, 2026

Uh oh!

rchl commented Apr 22, 2026

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

rchl May 3, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

rchl May 3, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

rchl commented May 3, 2026

Uh oh!

rwols commented May 3, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

rwols commented Apr 22, 2026 •

edited

Loading

netlify Bot commented Apr 22, 2026 •

edited

Loading

rchl May 3, 2026 •

edited

Loading

rchl May 3, 2026 •

edited

Loading