Where should `canonical_abi_*` be?

[saona-raimundo]

First of all, I am sorry if I misunderstood something or the issue has been brought up somewhere else. I tried my best to search through the issues in the repo. Please redirect if needed.

This is a question related to canonical_abi_free and canonical_abi_realloc: abi functions to work with memory representation of interface types. This might be related with #99 but I am not 100% sure.

The main question is: where should these functions be provided? In the module itself, or loaded separately? Should there be a abi-library that should be linked to the runtime before running wasm modules that use Interface types?

Details

In the current implementation of wit-bindgen, these functions end up in each wasm module. This has the advantage that the module is more self-contained, "isolated". But each module will contain a copy of these functions, generating code repetition.

On the other hand, wasi provides functions (today in wasi_snapshot_preview1). This means that modules using wasi need only import these functions, not define them themselves. For running modules that use these functions, wasi is loaded to the runtime.

[yowl]

But interface types can be used outside of wasi, so wouldn't you need these functions in those scenarios, e.g. emscripten in the browser?

[sbc100]

I think the idea is that every component needs to implement its own canonical_abi_free and canonical_abi_realloc because each one (potentially) has its own separate memory allocator acting on its own internal memory. This is not generally something the runtime can provide.

Modules can of course an allocator (and therefore share canonical_abi_free/canonical_abi_realloc implementations) but in that case they mostly likely part of the same component and would not need interface types (IIUC).

[lukewagner]

Agreed with @sbc100 that these functions need to be provided by the core module code that implements the component since allocation is a very language/runtime/toolchain/ABI-specific detail. To avoid code duplication, module imports can be used to factor out shared code from multiple components in a shared-nothing manner (example).

[saona-raimundo]

Thank you all!

@lukewagner, your link about factoring out shared code from multiple components is what I was missing! :)