Stream: git-wasmtime

Topic: wasmtime / issue #11869 Async libcalls "block" the store ...


view this post on Zulip Wasmtime GitHub notifications bot (Oct 15 2025 at 21:45):

alexcrichton opened issue #11869:

At this time the implementation of async libcalls in Wasmtime all use the block_on helper internally in the implementation. This has the property, though, that the store is "locked" while the libcall is waiting on the result meaning that in a component-model-async world it's not possible to make progress on anything else in the store while this is happening. This notably affects Store::run_concurrent as well where any select-ed async computation won't make progress because the wasm is locking up everything.

To fix this it will require async libcalls to be refactored/reimplemented to not close over the store for the duration of their execution. Instead something like Accessor will be required where mutable access to a store can be temporarily granted but otherwise it's not held across await points. In implementing this it'll fix run_concurrent to correctly and actually run various computations in the provided closure concurrently. This will also enable other concurrent tasks within the store to make progress while a libcall is blocked.

view this post on Zulip Wasmtime GitHub notifications bot (Oct 15 2025 at 21:45):

alexcrichton added the wasm-proposal:component-model-async label to Issue #11869.


Last updated: Dec 06 2025 at 06:05 UTC