Stream: git-wasmtime

Topic: wasmtime / PR #13706 feat(component): add Accessor async ...

Wasmtime GitHub notifications bot (Jun 22 2026 at 08:35):

Aditya1404Sal opened PR #13706 from Aditya1404Sal:add-accessor-instantiate-async to bytecodealliance:main:

Summary

Add Accessor::instantiate_async, an Accessor-side helper for instantiating an InstancePre into the current concurrent store.

This is intended for embedders that are already inside StoreContextMut::run_concurrent and need to instantiate prepared components while using the concurrent component runtime.

Problem

Inside run_concurrent, embedders are given an Accessor rather than a direct StoreContextMut.

That works for accessing store data with Accessor::with and for calling already-instantiated component functions with call_concurrent, but there is currently no public API for instantiating an InstancePre into that same concurrent store.

For hosts with dynamic component graphs, this makes lazy instantiation not-possible. In my use case I had to either:

• pre-instantiate possible callees before entering run_concurrent
• avoid lazy linking :(

This is limiting for hosts that want to instantiate linked components on demand during async component execution.

Change

Add:

Accessor::instantiate_async(&InstancePre<T>) -> Result<Instance>

The method uses the existing Accessor TLS mechanism to recover the current concurrent store and then delegates to InstancePre::instantiate_async.

This keeps lazy instantiation within the active concurrent event loop, without requiring a separately-held StoreContextMut.

I would really appreciate feedback on whether this is the right API shape for exposing this capability (ie. through Accessor)

Validation

Added a component-model async test that:

• prepares a component with Linker::instantiate_pre
• enters StoreContextMut::run_concurrent
• instantiates the same InstancePre twice through Accessor::instantiate_async
• verifies linker-provided imports are available
• calls exports from both instances with call_concurrent

Ran:

cargo test --test all accessor_can_instantiate_pre
cargo check -p wasmtime --features component-model,component-model-async,async

Wasmtime GitHub notifications bot (Jun 22 2026 at 10:40):

github-actions[bot] added the label wasmtime:api on PR #13706.

Wasmtime GitHub notifications bot (Jun 22 2026 at 20:44):

Aditya1404Sal has marked PR #13706 as ready for review.

Wasmtime GitHub notifications bot (Jun 22 2026 at 20:44):

Aditya1404Sal requested dicej for a review on PR #13706.

Wasmtime GitHub notifications bot (Jun 22 2026 at 20:44):

Aditya1404Sal requested wasmtime-core-reviewers for a review on PR #13706.

Wasmtime GitHub notifications bot (Jun 29 2026 at 04:05):

Aditya1404Sal commented on PR #13706:

CC: @dicej
Bringing this to your attention, Thank you!

Wasmtime GitHub notifications bot (Jun 29 2026 at 12:38):

alexcrichton unassigned dicej from PR #13706 feat(component): add Accessor async InstancePre instantiation.

Wasmtime GitHub notifications bot (Jun 29 2026 at 12:38):

alexcrichton requested alexcrichton for a review on PR #13706.

Wasmtime GitHub notifications bot (Jun 29 2026 at 12:43):

:cross_mark: alexcrichton closed without merge PR #13706.

Wasmtime GitHub notifications bot (Jun 29 2026 at 12:43):

alexcrichton commented on PR #13706:

Thanks for the PR, but this is not a sound implementation of this API. I agree it makes sense to expose this API, probably as instantiate_concurrent on Linker instead however, but implementing this will be a much deeper implementation I think than just a one-liner with a transmute. I've opened https://github.com/bytecodealliance/wasmtime/issues/13752 to track this.

Last updated: Jul 29 2026 at 05:03 UTC