Nathan Bedell (Aug 17 2025 at 14:34): Nathan Bedell (Aug 17 2025 at 14:34):Hey all, I'm trying my hand at trying to build a wasmtime host that allows a guest to be able to specify a GUI. Yet I'm having a heck of a time trying to get this to work with wasmtime.
One of the thing I'm running into is things (in particular: Resources, tables) needing to be Send / Sync to be able to use them with various GUI crates. And in working on this, I realized: It'd make my life a lot easier if resources were Copy -- that way I could just copy and move resources into closures as needed.
Is there any reason why this is not currently possible with wasmtime? Resources are basically just handles (indices) into a table, right? Shouldn't they be Copy?
I'm not sure if that would solve all my issues of trying to get this to work completely, but I think it'd help.
Another issue I'm running into is to be able to resolve resources within Send / Sync closures, I want to be able to wrap my ResourceTable in Arc<Mutex<>> -- yet as far as I can tell it's not really possible to have a Arc<Mutex<ResourceTable>> field in my state struct due to traits I have to implement like IoView.
Christof Petig (Aug 17 2025 at 15:08):A handle requires reference counting of the object, so, like Arc, it can't be Copy. Up to now there is no common convention on how to name a clone method, but I am quite sure Clone would be the way to go.
Alex Crichton (Aug 18 2025 at 15:05):I think it'd be reasonable to add Copy yeah, would you be up for sending a PR? I've historically meant to do this myself but never got around to it alas.
Alex Crichton (Aug 18 2025 at 15:05):Otherwise for your table-sharing case, you can use two resource tables -- one for WASI and one for your embedding, that way the WASI one wouldn't be behind a mutex but yours would be
Alex Crichton (Aug 18 2025 at 15:06):Oh and I'm assuming you mean Copy for Resource<T> in the Wasmtime API, if it's something else though I may be misunderstanding
Christof Petig (Aug 18 2025 at 19:29):I am still surprised that Copy is an option because each Resource<T> copy would call [resource-drop]T on the same ID, but that would surely confuse the resource table handling.
Thus I assumed the only option would be to call a [method]T.clone into the resource implementation which would return a new object with a new ID.
Christof Petig (Aug 18 2025 at 19:30):(oh, I misread, this is obviously about the host side)
Nathan Bedell (Aug 23 2025 at 14:48):Alex Crichton said:
I think it'd be reasonable to add
Copyyeah, would you be up for sending a PR? I've historically meant to do this myself but never got around to it alas.
Hey, sorry for the delay. Yeah, I'd be up for submitting a PR. I think Clone would work just fine as well if that's necessary for reference counting.
Last updated: Dec 06 2025 at 06:05 UTC