Risto (Aug 04 2020 at 21:24): Risto (Aug 04 2020 at 21:24):It seems that there is often a need to allocate memory in a module from the host environment and then write to that memory.
However, the module can have its own allocator in use and we cannot really make assumptions of how the allocator works.
Is there a way to allocate memory from host, for example by growing the memory of the module, without messing with a potential allocator?
The only way at the moment that I can think of is to export the allocator function and call it from the host. Growing the memory could be possible, but that makes the assumption that the wasm allocator will not use the memory that host allocates by growing.
Maybe in the future multiple memories or similar proposals solve this problem. Hmm.
fitzgen (he/him) (Aug 04 2020 at 21:26):Right now, the best thing to do is to export malloc/free functions. This is the kind of thing that interface types is being designed to handle well, without making the malloc/free generally visible.
Alexandru Ene (Aug 04 2020 at 21:26):The way I do it is by exposing wasm_alloc / wasm_free from the VM and calling those from the Host VM.
Risto (Aug 04 2020 at 21:34):Ah, yes. The interface types will probably require that functionality in order to achieve the copying/moving of data from one module to another in the shared-nothing linking case.
Thanks for clearing the way to go at the moment and thanks for referring to the proposal.
Last updated: Dec 23 2024 at 12:05 UTC