Allow critical extensions to run on the main thread

[paldepind]

From the Code documentation:

All extensions when activated run in our shared extension host process. This separate process for extensions ensures that VS Code remains responsive through-out.

I think that, in general, is a great approach as responsiveness is very important. However, I would argue that the current model could be even better. Currently, it does not account for some use cases. In these cases serious responsiveness problems can still be encountered.

I use Code together with VSCodeVim. Recently I was having a problem with one of the extensions I've installed. The extension was misbehaving and using a lot of CPU. Since both VSCodeVim and the misbehaving extension was running on the same thread editing was made completely impossible.

Extensions like VSCodeVim becomes their user's primary way of interacting with their editor. If the VSCodeVim extension is unresponsive due to another extension then the whole editing experience is unresponsive.

I would argue that key extensions like VSCodeVim should be allowed to run on the main thread or a thread separate from the other extensions. Otherwise using extensions like VSCodeVim will always result in a less responsive and less stable editing experience.

[aeschli]

To not run user extensions in the main process is core of VSCode's design. It's for UI responsiveness and to prevent data loss. There are no plans to change that.
But work is needed to prevent that extensions can block each other. If you can provide details on how the VSCodeVim got blocked?

[paldepind]

Hello @aeschli. Thank you for your response.

To not run user extensions in the main process is core of VSCode's design. It's for UI responsiveness and to prevent data loss.

Yes. I definitely agree with that. It's a great decision to ensure a responsive editor. No one likes a sluggish editing experience. UI responsiveness is very important and running extensions separate from the core editor ensures this.

I think we agree that the issue is that if some JavaScript is doing a long running synchronous operation it will freeze everything else running on its thread. Delegating extensions to a seperate thread ensures that extensions cannot affect the responsiveness of the main editor.

However, since all extensions run on the same thread it is very easy for once extension to make all the other extensions lag. In most cases this is not a bit issue. However, issues arrises with extensions like VSCodeVim.

When using VSCodeVim a users interactions with the editor goes through VSCodeVim. Moving the cursor, inserting text, deleting text, and similar things are all managed by VSCodeVim. VSCodeVim becomes part of the core UI for interacting with the editor. And since VSCodeVim is running on the extension thread it does not get the same responsiveness benefits that the inbuilt editing operations get.

The core editor should not run on the extension thread. This ensures responsiveness. But VSCodeVim is an extension that for it's users is part of the core editor. Therefore extensions like VSCodeVim should be allowed to run on the main thread like the rest of the core editor. Otherwise users of VSCodeVim will get a more sluggish experience than VSCode users who do not use VSCodeVim.

[rebornix]

This feature request will not be considered in the next 6-12 months roadmap and as such will be closed to keep the number of issues we have to maintain actionable. Thanks for understanding and happy coding!