Steve Williams (May 07 2020 at 12:20): Steve Williams (May 07 2020 at 12:20):Somebody just told me memory is per store rather than per instance. I'm assuming that's incorrect as it defeats the purpose of an instance.
However, it got me thinking. If retargeted assembler is per store, with seperate data per instance (as expected), is the appropriate protection in place to stop any self modifying code cleverness from occuring that would affect one instance from another.
Secondary: What if we want self modifying code cleverness.
Steve Williams (May 07 2020 at 12:22):I assume answer to latter is self modifying code isn't a necessity. Find another way of doing the same thing.
Steve Williams (May 07 2020 at 13:25):I get it. memory can be shared between instances & there are rare occasions you'd want to do that for inter-process communications.
all the same, each instance has a memory configuration that I'd like to be able to access in a performant manner in a callback as you almost have but andreas is objecting to for some reason I can't quite fathom.
Steve Williams (May 07 2020 at 14:18):how about :
if wasm_instance_set_host_info has been set, embedder wants instance specific information.
in this situation, the void* supplied to wasm_func_new_with_env could be the calling wasm_instance_t with anything embedder specific required hung of the pointer supplied to wasm_instance_set_host_info which I assume is retrieved using wasm_instance_get_host_info
that way the API doesn't need modifying. its just used in a way that might currently be undocumented.
Yury Delendik (May 07 2020 at 14:23):what's wrong with just plain wasm_func_new_with_env ? (Sorry, I still cannot get the problem described above)
Steve Williams (May 07 2020 at 14:25):I want the instance that called the callback accessible in the callback. throwing it into that void* is how I propose doing so without reving the API.
Yury Delendik (May 07 2020 at 14:25):for every instance you create wasm_func_t with unique env for wasm_func_new_with_env, connect env with instance. The function can be provided via imports or table. boom!
Yury Delendik (May 07 2020 at 14:26):without reving the API
Reviving host data to host itself? I'm confused
Yury Delendik (May 07 2020 at 14:27):Can you explain what's wrong with https://github.com/WebAssembly/wasm-c-api/blob/master/example/callback.c ?
Steve Williams (May 07 2020 at 14:30):You're suggesting passing the instance pointer as the void * to wasm_func_new_with_env.
That'd be neat, except you have to pass the wasm_func_t pointers into the function that creates the instance. you're wanting to pass as void * what we don't have yet :)
Steve Williams (May 07 2020 at 14:33):I've currently got this : https://pastebin.com/AX8Lqt34
Note how m_instance only becomes available after the wasm_func_t 's that define its imports have been defined.
Yury Delendik (May 07 2020 at 14:37):Making a circular data structure is really hard task, yes. Will the following pseudo code work? struct Env { wasm_instance_t *ins }; Env env = {nullptr}; func = wasm_func_new_with_env(..., &env, ...); env.ins = wasm_instance_new(..., [..func..]);
Steve Williams (May 07 2020 at 14:41):you're right. also, that's what I've already got. wasm_func_new_with_env takes a store pointer but it is instance specific as you pass it to the instance constructor & can have one of those per instance. so, turns out I'm wrong & so should apologize for taking everyone on a wild goose chase.
its fine. we can identify instances in callbacks, as yury correctly points out.
sorry everyone.
Yury Delendik (May 07 2020 at 14:47):Stipulation here is that the wasm module start function shall not call the callback. Which prevents it to do nicely in Command style modules. Reactor style of modules is a better fit here (https://github.com/WebAssembly/WASI/issues/13)
Steve Williams (May 07 2020 at 14:51):Not sure if that's relevant to my issue which I thought was closed. We have an init function which sets up a 3D scene, followed by a tick function every frame & a terminate function to tear it all down. wasm runtime stays live though all functions & is terminated after the last. thus far its acting as I'd expect. once again, guidance appreciated. almost got stuff happening on screen. a spinning cube by the end of the day maybe.
Last updated: Oct 23 2024 at 20:03 UTC