Jelle van den Hooff (Oct 30 2025 at 02:02): Jelle van den Hooff (Oct 30 2025 at 02:02):Hi, I wanted to leave a small usage report of run_concurrent and the Accessor API with the asynchronous component model. I am using wasmtime to embed a wasm component, and I want that component to run its tasks while I also invoke more tasks. In this specific case, I want to invoke more HTTP handlers while other handlers are already running. That is difficult because (it seems to me) that run_concurrent is the only way to get access to the Accessor I need to do new invocations, and run_concurrent takes a &mut self. (And I want more control than the standard wasi-http wrapper gives, so that's why I am not using that.)
In my mental right now, run_concurrent plays double duty -- it lets me start tasks with an accessor when I call it, and it lets the component make progress while it is running. I wish those were detangled. In an ideal world, I would use tokio::spawn a task that invokes something like run_concurrent on a component instance to let the component do work. Then, whenever I want to muck around with the state, I wish I could get an accessor temporarily by invoking some get_accessor that would temporarily pause the run_concurrent and let me invoke tasks or modify state.
My janky workaround (code) right now is to have a worker task that invokes run_concurrent, and that takes tasks from a queue to be invoked inside of that run_concurrent. I can then post tasks (code) to that queue without worrying about starting and stopping the run_concurrent. But it feels yucky.
Jelle van den Hooff (Oct 30 2025 at 02:03):It's also entirely possible I am doing something silly and there is an easier way to do this -- I am all ears :)
Jelle van den Hooff (Oct 30 2025 at 02:05):(And I tried to find issues describing this on the wasmtime repo but did not find anything that quite matched this.)
Joel Dice (Oct 30 2025 at 13:37):Jelle van den Hooff said:
My janky workaround (code) right now is to have a worker task that invokes run_concurrent, and that takes tasks from a queue to be invoked inside of that run_concurrent. I can then post tasks (code) to that queue without worrying about starting and stopping the run_concurrent.
FWIW, I think this is a fine approach, and matches what we do in wasmtime-wasi-http to support handling multiple concurrent incoming requests in a single instance. Perhaps we could generalize the pattern and make it a built-in part of the Wasmtime API.
Celarye (Oct 31 2025 at 16:14):I am also planning on using channels to solve this once I switch to WASI 0.3.
Perhaps we could generalize the pattern and make it a built-in part of the Wasmtime API.
I do think that simplifying the API by making this happen under the hood would be a nice improvement.
Last updated: Dec 06 2025 at 06:05 UTC