Stream: git-wasmtime

Topic: wasmtime / PR #14362 component: add `ResourceAny::resourc...

Wasmtime GitHub notifications bot (Sep 19 2026 at 20:45):

Byte-Naut requested pchickey for a review on PR #14362.

Wasmtime GitHub notifications bot (Sep 19 2026 at 20:45):

Byte-Naut requested wasmtime-core-reviewers for a review on PR #14362.

Wasmtime GitHub notifications bot (Sep 19 2026 at 20:45):

Byte-Naut opened PR #14362 from Byte-Naut:issue-14291-concurrent-resource-drop to bytecodealliance:main:

Closes #14291.

Motivation

With the component-model-async APIs there is currently no supported way to
drop a guest-exported ResourceAny when the host only has an Accessor,
e.g. inside Store::run_concurrent or a spawned AccessorTask.
resource_drop and resource_drop_async both need a StoreContextMut that
lives across the destructor call, which cannot escape an Accessor::with
closure, and blocking inside the closure would stall the store's event loop.
@SilverMira ran into this in #9946 and @alexcrichton suggested a
resource_drop_concurrent method as the missing piece.

Changes

• Add ResourceAny::resource_drop_concurrent(self, accessor: impl AsAccessor)
  behind component-model-async.

• Make StoreOpaque::queue_task pub(crate) so the new method can reuse the
  existing WorkerFunction path. No changes to the queue or event loop.

• Update the resource_drop docs to list all three variants and when each
  applies, which should also help with the documentation concerns raised in
  #9946.

• Tests: the ApiStyle::Concurrent arm of thread_index_via_resource_drop
  now exercises the new method, and a new
  resource_drop_concurrent_from_accessor_task test reproduces the
  AccessorTask scenario from the issue.

Design

The drop is queued as a WorkerFunction on the store's worker fiber using
the same oneshot-plus-StoreToken pattern as start_instance. The
Accessor::with closure only creates the channel and enqueues the work, so
the store borrow ends before the caller awaits the result. Running the
destructor on the worker fiber keeps guest code off the embedder's stack.
resource_drop_impl is shared unchanged, so resource table handling,
may_enter checks, and sync-call bookkeeping are identical to the existing
sync and async variants.

Two behaviours worth calling out for review:

• Destructor errors are sent back to the caller over the channel rather than
  surfacing as an event loop error.

• Once the future has been polled and the drop is queued, dropping the future
  does not cancel the drop; the queued work still runs and the send failure
  is ignored.

Both are documented on the method. Happy to adjust either if a different
policy is preferred.

Testing

The test component's destructor calls thread.index and traps if it is zero,
so the tests check that the destructor actually runs in a guest thread
context, not just that no error is returned.

cargo test --test all resource_drop

Locally: fmt, clippy, cargo doc --all-features with -D warnings, and the
component_model test suite all pass.

Out of scope

bindgen-generated resource bindings currently only expose resource_drop
and resource_drop_async. Adding a _concurrent variant there seemed better
as a follow-up once the core API shape is settled, but I can fold it in here
if preferred.

This PR was written with assistance from Claude (Anthropic); I reviewed and
tested the changes and take responsibility for them, per the Bytecode
Alliance AI Tool Use Policy.

Wasmtime GitHub notifications bot (Sep 19 2026 at 20:49):

Byte-Naut edited PR #14362:

Closes #14291.

Motivation

With the component-model-async APIs there is currently no supported way to drop a guest-exported ResourceAny when the host only has an Accessor, e.g. inside Store::run_concurrent or a spawned AccessorTask. resource_drop and resource_drop_async both need a StoreContextMut that lives across the destructor call, which cannot escape an Accessor::with closure, and blocking inside the closure would stall the store's event loop. @SilverMira ran into this in #9946 and @alexcrichton suggested a resource_drop_concurrent method as the missing piece.

Changes

• Add ResourceAny::resource_drop_concurrent(self, accessor: impl AsAccessor) behind component-model-async.
• Make StoreOpaque::queue_task pub(crate) so the new method can reuse the existing WorkerFunction path. No changes to the queue or event loop.
• Update the resource_drop docs to list all three variants and when each applies, which should also help with the documentation concerns raised in #9946.
• Tests: the ApiStyle::Concurrent arm of thread_index_via_resource_drop now exercises the new method, and a new resource_drop_concurrent_from_accessor_task test reproduces the AccessorTask scenario from the issue.

Design

The drop is queued as a WorkerFunction on the store's worker fiber using the same oneshot-plus-StoreToken pattern as start_instance. The Accessor::with closure only creates the channel and enqueues the work, so the store borrow ends before the caller awaits the result. Running the destructor on the worker fiber keeps guest code off the embedder's stack. resource_drop_impl is shared unchanged, so resource table handling, may_enter checks, and sync-call bookkeeping are identical to the existing sync and async variants.

Two behaviours worth calling out for review:

• Destructor errors are sent back to the caller over the channel rather than surfacing as an event loop error.
• Once the future has been polled and the drop is queued, dropping the future does not cancel the drop; the queued work still runs and the send failure is ignored.

Both are documented on the method. Happy to adjust either if a different policy is preferred.

Testing

The test component's destructor calls thread.index and traps if it is zero, so the tests check that the destructor actually runs in a guest thread context, not just that no error is returned.

cargo test --test all resource_drop

Locally: fmt, clippy, cargo doc --all-features with -D warnings, and the component_model test suite all pass.

Out of scope

bindgen-generated resource bindings currently only expose resource_drop and resource_drop_async. Adding a _concurrent variant there seemed better as a follow-up once the core API shape is settled, but I can fold it in here if preferred.

This PR was written with assistance from Claude (Anthropic); I reviewed and tested the changes and take responsibility for them, per the Bytecode Alliance AI Tool Use Policy.

Wasmtime GitHub notifications bot (Sep 19 2026 at 21:01):

Byte-Naut edited PR #14362:

Closes #14291.

Motivation

With the component-model-async APIs there is currently no supported way to drop a guest-exported ResourceAny when the host only has an Accessor, e.g. inside Store::run_concurrent or a spawned AccessorTask. resource_drop and resource_drop_async both need a StoreContextMut that lives across the destructor call, which cannot escape an Accessor::with closure, and blocking inside the closure would stall the store's event loop. @SilverMira ran into this in #9946 and @alexcrichton suggested a resource_drop_concurrent method as the missing piece.

Changes

• Add ResourceAny::resource_drop_concurrent(self, accessor: impl AsAccessor) behind component-model-async.
• Make StoreOpaque::queue_task pub(crate) so the new method can reuse the existing WorkerFunction path. No changes to the queue or event loop.
• Update the resource_drop docs to list all three variants and when each applies, which should also help with the documentation concerns raised in #9946.
• Tests: the ApiStyle::Concurrent arm of thread_index_via_resource_drop now exercises the new method, and a new resource_drop_concurrent_from_accessor_task test reproduces the AccessorTask scenario from the issue.

Design

The drop is queued as a WorkerFunction on the store's worker fiber using the same oneshot-plus-StoreToken pattern as start_instance. The Accessor::with closure only creates the channel and enqueues the work, so the store borrow ends before the caller awaits the result. Running the destructor on the worker fiber keeps guest code off the embedder's stack. resource_drop_impl is shared unchanged, so resource table handling, may_enter checks, and sync-call bookkeeping are identical to the existing sync and async variants.

Two behaviours worth calling out for review:

• Destructor errors are sent back to the caller over the channel rather than surfacing as an event loop error.
• Once the future has been polled and the drop is queued, dropping the future does not cancel the drop; the queued work still runs and the send failure is ignored.

Both are documented on the method. Happy to adjust either if a different policy is preferred.

Testing

The test component's destructor calls thread.index and traps if it is zero, so the tests check that the destructor actually runs in a guest thread context, not just that no error is returned.

cargo test --test all resource_drop

Locally: fmt, clippy, cargo doc --all-features with -D warnings, and the component_model test suite all pass.

Out of scope

bindgen-generated resource bindings currently only expose resource_drop and resource_drop_async. Adding a _concurrent variant there seemed better as a follow-up once the core API shape is settled, but I can fold it in here if preferred.

Wasmtime GitHub notifications bot (Sep 19 2026 at 21:06):

Byte-Naut edited PR #14362:

Closes #14291.

Motivation

With the component-model-async APIs there is currently no supported way to drop a guest-exported ResourceAny when the host only has an Accessor, e.g. inside Store::run_concurrent or a spawned AccessorTask. resource_drop and resource_drop_async both need a StoreContextMut that lives across the destructor call, which cannot escape an Accessor::with closure, and blocking inside the closure would stall the store's event loop. @SilverMira ran into this in #9946 and @alexcrichton suggested a resource_drop_concurrent method as the missing piece.

Changes

• Add ResourceAny::resource_drop_concurrent(self, accessor: impl AsAccessor) behind component-model-async.
• Make StoreOpaque::queue_task pub(crate) so the new method can reuse the existing WorkerFunction path. No changes to the queue or event loop.
• Update the resource_drop docs to list all three variants and when each applies, which should also help with the documentation concerns raised in #9946.
• Tests: the ApiStyle::Concurrent arm of thread_index_via_resource_drop now exercises the new method, and a new resource_drop_concurrent_from_accessor_task test reproduces the AccessorTask scenario from the issue.

Design

The drop is queued as a WorkerFunction on the store's worker fiber using the same oneshot-plus-StoreToken pattern as start_instance. The Accessor::with closure only creates the channel and enqueues the work, so the store borrow ends before the caller awaits the result. Running the destructor on the worker fiber keeps guest code off the embedder's stack. resource_drop_impl is shared unchanged, so resource table handling, may_enter checks, and sync-call bookkeeping are identical to the existing sync and async variants.

Two behaviours worth calling out for review:

• Destructor errors are sent back to the caller over the channel rather than surfacing as an event loop error.
• Once the future has been polled and the drop is queued, dropping the future does not cancel the drop; the queued work still runs and the send failure is ignored.

Both are documented on the method. Happy to adjust either if a different policy is preferred.

Testing

The test component's destructor calls thread.index and traps if it is zero, so the tests check that the destructor actually runs in a guest thread context, not just that no error is returned.

cargo test --test all resource_drop

Locally: fmt, clippy, cargo doc --all-features with -D warnings, and the component_model test suite all pass.

Out of scope

bindgen-generated resource bindings currently only expose resource_drop and resource_drop_async. Adding a _concurrent variant there seemed better as a follow-up once the core API shape is settled, but I can fold it in here if preferred.

Developed with assistance from Claude (Anthropic). Per the Bytecode Alliance AI Tool Use Policy, I'm the author and accountable for this change.

Wasmtime GitHub notifications bot (Sep 19 2026 at 22:44):

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

Last updated: Sep 20 2026 at 18:08 UTC