extension_host: Avoid creating a Tokio runtime#45990
Merged
Veykril merged 2 commits intozed-industries:mainfrom Jan 4, 2026
Merged
extension_host: Avoid creating a Tokio runtime#45990Veykril merged 2 commits intozed-industries:mainfrom
Veykril merged 2 commits intozed-industries:mainfrom
Conversation
Signed-off-by: Marco Mihai Condrache <52580954+marcocondrache@users.noreply.github.com>
Signed-off-by: Marco Mihai Condrache <52580954+marcocondrache@users.noreply.github.com>
Member
|
Just a heads-up (I haven't actually reviewed this PR thoroughly): this part of codebase is a bit sensitive to whether it's running on background vs foreground thread. In practice, we want to off-load as much work onto background executor as possible so as to not load extensions using foreground thread whenever possible. See #41398 |
Contributor
Author
|
@osiewicz thanks a lot for the heads-up. I’ve tried to reflect this by splitting the loading task into two parts. The heavier work (compilation and parsing) still runs on the background executor, while the remaining part, which is mostly wasi calls, runs on gpui_tokio and should be I/O bound. |
Veykril
approved these changes
Jan 4, 2026
rtfeldman
pushed a commit
that referenced
this pull request
Jan 5, 2026
While profiling Zed, I noticed around 12 `tokio-runtime-worker` threads. Since `gpui_tokio` runs a Tokio runtime with only two worker threads, this meant something else was spinning up a default Tokio runtime (My machine has 10 cores). After digging into it a bit, it looks like `wasmtime-wasi` needs a Tokio runtime for some of its calls. That’s also why we run extension tasks on `gpui-tokio` in the first place. Reproduction case: 1. Run a clean Zed build. 2. Sample the process → only 2–3 Tokio threads. 3. Install a WASM extension (for example https://github.com/zed-extensions/nix), which shouldn’t pull in anything that creates its own runtime. 4. Sample the process again → 10+ Tokio worker threads show up. ``` marcocondrache@xawed ~/P/zed (main)> sample 34260 1 | grep -E "Thread_" Sampling process 34260 for 1 second with 1 millisecond of run time between samples Sampling completed, processing symbols... Sample analysis of process 34260 written to file /tmp/zed_2026-01-03_112527_5pq7.sample.txt 744 Thread_3086626 DispatchQueue_1: com.apple.main-thread (serial) 744 Thread_3086629: RayonWorker0 .... 744 Thread_3086651: MacWatcher 744 Thread_3086653: MacWatcher 744 Thread_3086661: com.apple.NSEventThread 744 Thread_3086680: tokio-runtime-worker 744 Thread_3086681: tokio-runtime-worker ... 744 Thread_3087087: tokio-runtime-worker 744 Thread_3087089: tokio-runtime-worker 744 Thread_3087090: tokio-runtime-worker 744 Thread_3087091: tokio-runtime-worker 744 Thread_3087092: tokio-runtime-worker 744 Thread_3087093: tokio-runtime-worker 744 Thread_3087094: tokio-runtime-worker 744 Thread_3087095: tokio-runtime-worker 744 Thread_3087096: tokio-runtime-worker 744 Thread_3087097: tokio-runtime-worker ... ``` Release Notes: - Reduced number of threads when using extensions --------- Signed-off-by: Marco Mihai Condrache <52580954+marcocondrache@users.noreply.github.com>
LivioGama
pushed a commit
to LivioGama/zed
that referenced
this pull request
Jan 20, 2026
While profiling Zed, I noticed around 12 `tokio-runtime-worker` threads. Since `gpui_tokio` runs a Tokio runtime with only two worker threads, this meant something else was spinning up a default Tokio runtime (My machine has 10 cores). After digging into it a bit, it looks like `wasmtime-wasi` needs a Tokio runtime for some of its calls. That’s also why we run extension tasks on `gpui-tokio` in the first place. Reproduction case: 1. Run a clean Zed build. 2. Sample the process → only 2–3 Tokio threads. 3. Install a WASM extension (for example https://github.com/zed-extensions/nix), which shouldn’t pull in anything that creates its own runtime. 4. Sample the process again → 10+ Tokio worker threads show up. ``` marcocondrache@xawed ~/P/zed (main)> sample 34260 1 | grep -E "Thread_" Sampling process 34260 for 1 second with 1 millisecond of run time between samples Sampling completed, processing symbols... Sample analysis of process 34260 written to file /tmp/zed_2026-01-03_112527_5pq7.sample.txt 744 Thread_3086626 DispatchQueue_1: com.apple.main-thread (serial) 744 Thread_3086629: RayonWorker0 .... 744 Thread_3086651: MacWatcher 744 Thread_3086653: MacWatcher 744 Thread_3086661: com.apple.NSEventThread 744 Thread_3086680: tokio-runtime-worker 744 Thread_3086681: tokio-runtime-worker ... 744 Thread_3087087: tokio-runtime-worker 744 Thread_3087089: tokio-runtime-worker 744 Thread_3087090: tokio-runtime-worker 744 Thread_3087091: tokio-runtime-worker 744 Thread_3087092: tokio-runtime-worker 744 Thread_3087093: tokio-runtime-worker 744 Thread_3087094: tokio-runtime-worker 744 Thread_3087095: tokio-runtime-worker 744 Thread_3087096: tokio-runtime-worker 744 Thread_3087097: tokio-runtime-worker ... ``` Release Notes: - Reduced number of threads when using extensions --------- Signed-off-by: Marco Mihai Condrache <52580954+marcocondrache@users.noreply.github.com>
LivioGama
pushed a commit
to LivioGama/zed
that referenced
this pull request
Jan 20, 2026
While profiling Zed, I noticed around 12 `tokio-runtime-worker` threads. Since `gpui_tokio` runs a Tokio runtime with only two worker threads, this meant something else was spinning up a default Tokio runtime (My machine has 10 cores). After digging into it a bit, it looks like `wasmtime-wasi` needs a Tokio runtime for some of its calls. That’s also why we run extension tasks on `gpui-tokio` in the first place. Reproduction case: 1. Run a clean Zed build. 2. Sample the process → only 2–3 Tokio threads. 3. Install a WASM extension (for example https://github.com/zed-extensions/nix), which shouldn’t pull in anything that creates its own runtime. 4. Sample the process again → 10+ Tokio worker threads show up. ``` marcocondrache@xawed ~/P/zed (main)> sample 34260 1 | grep -E "Thread_" Sampling process 34260 for 1 second with 1 millisecond of run time between samples Sampling completed, processing symbols... Sample analysis of process 34260 written to file /tmp/zed_2026-01-03_112527_5pq7.sample.txt 744 Thread_3086626 DispatchQueue_1: com.apple.main-thread (serial) 744 Thread_3086629: RayonWorker0 .... 744 Thread_3086651: MacWatcher 744 Thread_3086653: MacWatcher 744 Thread_3086661: com.apple.NSEventThread 744 Thread_3086680: tokio-runtime-worker 744 Thread_3086681: tokio-runtime-worker ... 744 Thread_3087087: tokio-runtime-worker 744 Thread_3087089: tokio-runtime-worker 744 Thread_3087090: tokio-runtime-worker 744 Thread_3087091: tokio-runtime-worker 744 Thread_3087092: tokio-runtime-worker 744 Thread_3087093: tokio-runtime-worker 744 Thread_3087094: tokio-runtime-worker 744 Thread_3087095: tokio-runtime-worker 744 Thread_3087096: tokio-runtime-worker 744 Thread_3087097: tokio-runtime-worker ... ``` Release Notes: - Reduced number of threads when using extensions --------- Signed-off-by: Marco Mihai Condrache <52580954+marcocondrache@users.noreply.github.com>
LivioGama
pushed a commit
to LivioGama/zed
that referenced
this pull request
Feb 15, 2026
While profiling Zed, I noticed around 12 `tokio-runtime-worker` threads. Since `gpui_tokio` runs a Tokio runtime with only two worker threads, this meant something else was spinning up a default Tokio runtime (My machine has 10 cores). After digging into it a bit, it looks like `wasmtime-wasi` needs a Tokio runtime for some of its calls. That’s also why we run extension tasks on `gpui-tokio` in the first place. Reproduction case: 1. Run a clean Zed build. 2. Sample the process → only 2–3 Tokio threads. 3. Install a WASM extension (for example https://github.com/zed-extensions/nix), which shouldn’t pull in anything that creates its own runtime. 4. Sample the process again → 10+ Tokio worker threads show up. ``` marcocondrache@xawed ~/P/zed (main)> sample 34260 1 | grep -E "Thread_" Sampling process 34260 for 1 second with 1 millisecond of run time between samples Sampling completed, processing symbols... Sample analysis of process 34260 written to file /tmp/zed_2026-01-03_112527_5pq7.sample.txt 744 Thread_3086626 DispatchQueue_1: com.apple.main-thread (serial) 744 Thread_3086629: RayonWorker0 .... 744 Thread_3086651: MacWatcher 744 Thread_3086653: MacWatcher 744 Thread_3086661: com.apple.NSEventThread 744 Thread_3086680: tokio-runtime-worker 744 Thread_3086681: tokio-runtime-worker ... 744 Thread_3087087: tokio-runtime-worker 744 Thread_3087089: tokio-runtime-worker 744 Thread_3087090: tokio-runtime-worker 744 Thread_3087091: tokio-runtime-worker 744 Thread_3087092: tokio-runtime-worker 744 Thread_3087093: tokio-runtime-worker 744 Thread_3087094: tokio-runtime-worker 744 Thread_3087095: tokio-runtime-worker 744 Thread_3087096: tokio-runtime-worker 744 Thread_3087097: tokio-runtime-worker ... ``` Release Notes: - Reduced number of threads when using extensions --------- Signed-off-by: Marco Mihai Condrache <52580954+marcocondrache@users.noreply.github.com>
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 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.
While profiling Zed, I noticed around 12
tokio-runtime-workerthreads. Sincegpui_tokioruns a Tokio runtime with only two worker threads, this meant something else was spinning up a default Tokio runtime (My machine has 10 cores).After digging into it a bit, it looks like
wasmtime-wasineeds a Tokio runtime for some of its calls. That’s also why we run extension tasks ongpui-tokioin the first place.Reproduction case:
Release Notes: