API does not fully support sharing objects between multiple modules

[lexaknyazev]

Multiple modules may need to use the same Memory, Function, Table, or Global objects. Example scenarios that seem to be currently unsupported:

• Creating a Memory object, filling it with data, then importing it into multiple modules. Potential solution: move WasmerStore out of WasmModule (this may require adjusting finalizers).
• Exporting a Function from one Module and importing it into another. Potential solution: relax WasmInstanceBuilder.addFunction to accept WasmFunction or add a new WasmInstanceBuilder.addWasmFunction method.
• Creating a Global object and importing it into multiple modules.
• Importing a Global exported from another module.

[liamappelbe]

Hmmm. I hadn't considered this use case. Should be pretty easy to fix, but I probably won't fix it before we publish the initial version. Since this feels like an edge case to me, I'll try to fix it while keeping the API simple for single module users (eg, the user shouldn't have to know that WasmerStore exists unless they want to do this).

@lexaknyazev I've got a few questions:

1. Presumably the modules would all need to use the same store object? So I should add an assert that imported objects have the same store, right?
2. What stops multiple modules using the same memory from clobbering each other?
3. I haven't added any API for tables yet, because I haven't seen a concrete use case. What sort of C code would need a table?

[lexaknyazev]

Presumably the modules would all need to use the same store object? So I should add an assert that imported objects have the same store, right?

Modules that use the same objects will need to use the same store. Note that there's no concept of user-accessible stores on the web as all modules within a single execution context share the same store (probably with some restrictions around cross-origin sources, not sure atm).

What stops multiple modules using the same memory from clobbering each other?

Nothing. The memory layout may be well-defined and modules may be designed around that (with required offsets and so on).

What sort of C code would need a table?

Can't say much about C code, but here are the Tables' use cases:

• linking modules after instantiation (e.g. for deferred loading);
• runtime mutation of exported functions (basically, an extra level of function call indirection that may be reconfigured at any time by either side);
• working with opaque references to external objects (requires reference types support).