Stream: general

Topic: wasm_memory_t stability

Steve Williams (May 09 2020 at 10:25):

Guys, I have setup with a single memory block exported from an instance, which I resolve thus : https://pastebin.com/LpemFPVp
Was hoping that'd be it, then I could just use the wasm_memory_t pointer, but apparently not.
Seems you release then allocate a new one under the hood sometimes so I have to walk my list of exports every callback to find what the current valid wasm_memory_t is. This is not performant as an export list could potentially be huge.

I get you have to reallocate the block sometimes. Surely wasm_memory_t has sufficient abstraction to enable you to do this ?

Please wise me up if its my stupid :)

Steve Williams (May 09 2020 at 11:17):

resolved : Shouldn't call wasm_extern_vec_delete(&exports);

... at that point. needs to persist.

Steve Williams (May 09 2020 at 11:18):

this means I have to carry around potentially a huge export table where I only care about a couple of entries.

Steve Williams (May 09 2020 at 11:44):

checkpoint: cube on the screen.

next up to spin it which is trivial, but gets me to where I wanted to be for first pass feasibility study.

thanks all, great work. sorry for my derps. takes a while to get your head around a new system :)

Steve Williams (May 09 2020 at 14:52):

.

Yury Delendik (May 09 2020 at 14:53):

there is wasm_extern_copy (see https://github.com/WebAssembly/wasm-c-api/blob/master/include/wasm.h#L331)

Steve Williams (May 09 2020 at 14:55):

thanks. so I create another exern block thingy & copy the ones I want to keep into that. sounds like a plan :) cheers.

Last updated: Nov 22 2024 at 17:03 UTC