Stream: git-wasmtime

Topic: wasmtime / issue #11226 Support running tasks for all ins...

Wasmtime GitHub notifications bot (Jul 11 2025 at 21:00):

dicej opened issue #11226:

Currently, if you have a Store with multiple component instances, you can only run an event loop (via e.g. Instance::run) for one of those instances at a time. We'd like to remove that restriction and allow all the instances to make progress concurrently.

Note that this will require moving some or all of ConcurrentState out of ComponentInstance and into Store. In fact, ConcurrentState originally _did_ live in Store; I moved it to ComponentInstance when I discovered that wasmtime-wast reuses the same store to run multiple instances, which caused issues when one of those instances trapped with unfinished tasks still pending and subsequent instances tried to resume those tasks. If we move that state back into Store, we'll need to take care to avoid such cross-talk (whether due to serial or concurrent use of instances within a single store) by immediately purging any tasks and associated state belonging to a trapped instance.

Wasmtime GitHub notifications bot (Jul 11 2025 at 21:00):

dicej added the wasm-proposal:component-model-async label to Issue #11226.

Wasmtime GitHub notifications bot (Jul 11 2025 at 21:03):

dicej edited issue #11226:

Currently, if you have a Store with multiple component instances, you can only run an event loop (via e.g. Instance::run) for one of those instances at a time. We'd like to remove that restriction and allow all the instances to make progress concurrently.

Note that this will require moving some or all of ConcurrentState out of ComponentInstance and into Store. In fact, ConcurrentState originally _did_ live in Store; I moved it to ComponentInstance when I discovered that wasmtime-wast reuses the same store to run multiple instances, which caused issues when one of those instances trapped with unfinished tasks still pending and subsequent instances tried to resume those tasks. If we move that state back into Store, we'll need to take care to avoid such cross-talk (whether due to serial or concurrent use of instances within a single store) by immediately purging any tasks and associated state belonging to a trapped instance.

This change should additionally allow us to move methods like Instance::{stream,future} to Store[ContextMut] since streams and futures would no longer be instance-specific. That, in turn, should allow us to remove the Access[or]::instance methods since e.g. host functions would no longer need access to the specific instance they're being called from.

Wasmtime GitHub notifications bot (Jul 11 2025 at 21:23):

dicej edited issue #11226:

Currently, if you have a Store with multiple component instances, you can only run an event loop (via e.g. Instance::run) for one of those instances at a time. We'd like to remove that restriction and allow all the instances to make progress concurrently.

Note that this might require moving some or all of ConcurrentState out of ComponentInstance and into Store. In fact, ConcurrentState originally _did_ live in Store; I moved it to ComponentInstance when I discovered that wasmtime-wast reuses the same store to run multiple instances, which caused issues when one of those instances trapped with unfinished tasks still pending and subsequent instances tried to resume those tasks. If we move that state back into Store, we'll need to take care to avoid such cross-talk (whether due to serial or concurrent use of instances within a single store) by immediately purging any tasks and associated state belonging to a trapped instance.

This change should additionally allow us to move methods like Instance::{stream,future} to Store[ContextMut] since streams and futures would no longer be instance-specific. That, in turn, should allow us to remove the Access[or]::instance methods since e.g. host functions would no longer need access to the specific instance they're being called from.

Wasmtime GitHub notifications bot (Jul 11 2025 at 21:24):

dicej edited issue #11226:

Currently, if you have a Store with multiple component instances, you can only run an event loop (via e.g. Instance::run) for one of those instances at a time. We'd like to remove that restriction and allow all the instances to make progress concurrently.

Note that this will require moving some or all of ConcurrentState out of ComponentInstance and into Store. In fact, ConcurrentState originally _did_ live in Store; I moved it to ComponentInstance when I discovered that wasmtime-wast reuses the same store to run multiple instances, which caused issues when one of those instances trapped with unfinished tasks still pending and subsequent instances tried to resume those tasks. If we move that state back into Store, we'll need to take care to avoid such cross-talk (whether due to serial or concurrent use of instances within a single store) by immediately purging any tasks and associated state belonging to a trapped instance.

This change should additionally allow us to move methods like Instance::{stream,future} to Store[ContextMut] since streams and futures would no longer be instance-specific. That, in turn, should allow us to remove the Access[or]::instance methods since e.g. host functions would no longer need access to the specific instance they're being called from.

Wasmtime GitHub notifications bot (Sep 03 2025 at 17:49):

alexcrichton commented on issue #11226:

@dicej and I talked about this today and we mostly concluded this is a bit more nuanced than originally anticipated. Our current thinking is:

• We'll move everything to the Store
• We'll update wasmtime-wast to make a store-per-component-instance.

The basic conclusion we reached is that the main benefit of today's design is that we can conceptually throw away the entirety of all async state when a trap happens. While we don't proactively currently do that all embeddings morally do that and we could in theory start doing it within Wasmtime. Simply applying what this issue says makes this quite complicated because we'd have to either (a) keep concurrent state for all instances separate or (b) keep track of which parts of state in the store map to one instance. Our conclusion was that this probably isn't worth it and we probably want to elevate the "throw the instance state away" to "throw the whole store away".

This requires updating wasmtime-wast though which reuses a store across trapping instances. And this also touches on more component-model level things which we want to discuss with others as well. More updates after meetings next week...

Wasmtime GitHub notifications bot (Sep 08 2025 at 20:36):

alexcrichton assigned alexcrichton to issue #11226.

Wasmtime GitHub notifications bot (Sep 08 2025 at 20:36):

alexcrichton assigned dicej to issue #11226.

Wasmtime GitHub notifications bot (Sep 30 2025 at 15:56):

dicej edited issue #11226:

Currently, if you have a Store with multiple component instances, you can only run an event loop (via e.g. Instance::run_concurrent) for one of those instances at a time. We'd like to remove that restriction and allow all the instances to make progress concurrently.

Note that this will require moving some or all of ConcurrentState out of ComponentInstance and into Store. In fact, ConcurrentState originally _did_ live in Store; I moved it to ComponentInstance when I discovered that wasmtime-wast reuses the same store to run multiple instances, which caused issues when one of those instances trapped with unfinished tasks still pending and subsequent instances tried to resume those tasks. If we move that state back into Store, we'll need to take care to avoid such cross-talk (whether due to serial or concurrent use of instances within a single store) by immediately purging any tasks and associated state belonging to a trapped instance.

This change should additionally allow us to move methods like Instance::{stream,future} to Store[ContextMut] since streams and futures would no longer be instance-specific. That, in turn, should allow us to remove the Access[or]::instance methods since e.g. host functions would no longer need access to the specific instance they're being called from.

Wasmtime GitHub notifications bot (Oct 06 2025 at 20:16):

dicej closed issue #11226:

Currently, if you have a Store with multiple component instances, you can only run an event loop (via e.g. Instance::run_concurrent) for one of those instances at a time. We'd like to remove that restriction and allow all the instances to make progress concurrently.

Note that this will require moving some or all of ConcurrentState out of ComponentInstance and into Store. In fact, ConcurrentState originally _did_ live in Store; I moved it to ComponentInstance when I discovered that wasmtime-wast reuses the same store to run multiple instances, which caused issues when one of those instances trapped with unfinished tasks still pending and subsequent instances tried to resume those tasks. If we move that state back into Store, we'll need to take care to avoid such cross-talk (whether due to serial or concurrent use of instances within a single store) by immediately purging any tasks and associated state belonging to a trapped instance.

This change should additionally allow us to move methods like Instance::{stream,future} to Store[ContextMut] since streams and futures would no longer be instance-specific. That, in turn, should allow us to remove the Access[or]::instance methods since e.g. host functions would no longer need access to the specific instance they're being called from.

Last updated: Dec 06 2025 at 07:03 UTC