Stream: git-wasmtime

Topic: wasmtime / Issue #1934 Share memory between linked modules

Wasmtime GitHub notifications bot (Jun 27 2020 at 16:57):

bubagl opened Issue #1934:

I've tried to experiment with linking several wasm modules together (https://github.com/bytecodealliance/wasmtime/blob/master/examples/linking.rs). It works but it seems the memory isn't "shared". For instance it is impossible to send a string between modules. Am I missing something? Thanks!

Wasmtime GitHub notifications bot (Jun 27 2020 at 17:25):

bjorn3 commented on Issue #1934:

WASI modules export their memory. They don't import it. This means that every WASI module has it's own memory that it gives access to others to. It never accesses memory of other modules.

Wasmtime GitHub notifications bot (Jun 27 2020 at 19:12):

bubagl commented on Issue #1934:

It never accesses memory of other modules.

Is there any way to send data between different modules except "by value"?

Wasmtime GitHub notifications bot (Jun 27 2020 at 19:19):

bjorn3 commented on Issue #1934:

You need to make all modules except for at most one import the memory instead of export. This means that you will have to use wasm32-unknown-unknown instead of wasm32-wasi and then use I think -Clink-arg=--import-memory to tell LLD to import the memory instead of export it.

Wasmtime GitHub notifications bot (Jun 27 2020 at 20:55):

bubagl commented on Issue #1934:

have to use wasm32-unknown-unknown

but in this case the module wouldn't be able to use any system/wasi call.

Wasmtime GitHub notifications bot (Jun 27 2020 at 23:56):

bubagl commented on Issue #1934:

Btw, what is the usecase of merging multiple wasms into a single instance?

Wasmtime GitHub notifications bot (Jun 29 2020 at 01:30):

bubagl edited a comment on Issue #1934:

Btw, what is the usecase of merging multiple wasms into a single instance? Does this feature has any limitations?

Wasmtime GitHub notifications bot (Jun 29 2020 at 14:14):

alexcrichton commented on Issue #1934:

Today it's somewhat difficult to set this up. Wasm modules today can have at most one memory, which means you can't natively, in wasm, copy between memories (since you can only reference at most up to one). This means that there's two ways you can set up modules which "share" a linear memory:

• The host itself can copy between memories. On the host you can reference all the memories you want, but you'd have to implement the boilerplate of marshalling messages between modules. Eventually with interface types it's intended that the runtime can do this for you.

• You can compile all wasm modules to import a memory, and then the host provides a single memory to each module. This is a form of "dynamic linking" in the wasm world, but AFAIK the support is somewhat limited here in toolchains. I believe it's technically possible to get things working but you're sort of on your own in the way of documentation, examples, etc.

I don't think you're currently missing anything about wasm, this is sort of just about how the state of toolchains are today. We're working to improve things with interface types, though, as well as the module linking proposal which will guide toolchains towards wasm modules which are easily linked together.

Is there any way to send data between different modules except "by value"?

Functions can only pass integers around at this time. With interface types you'll be able to pass richer types. Passing a pointer, however, will only work if the modules reference the same memory or know which memory the pointer is pointing to.

Btw, what is the usecase of merging multiple wasms into a single instance? Does this feature has any limitations?

Wasmtime doesn't do this and this sounds like more of a toolchain question? There's various reasons you might want to do this but why is this question coming up? Do you have a use case in mind you'd like to game out?

Wasmtime GitHub notifications bot (Jun 29 2020 at 14:29):

bubagl commented on Issue #1934:

We're working to improve things with interface types

Interface types are are defined by IDL (WebIDL), correct?

Wasmtime GitHub notifications bot (Jun 29 2020 at 14:34):

bubagl edited a comment on Issue #1934:

We're working to improve things with interface types

Interface types are are defined by IDL (WebIDL), correct? Do you already have interface types working (even as beta)?

Wasmtime GitHub notifications bot (Jun 29 2020 at 15:06):

alexcrichton commented on Issue #1934:

A previous iteration of the proposal worked with WebIDL but they are no longer based on WebIDL (although there will be a definition of a translation from WebIDL to interface types). Currently interface types are not implemented in Wasmtime.

Wasmtime GitHub notifications bot (Jun 29 2020 at 15:21):

bubagl commented on Issue #1934:

A previous iteration of the proposal worked with WebIDL

That's interesting! What the new iteration is based on?

Wasmtime GitHub notifications bot (Jun 29 2020 at 15:52):

tschneidereit commented on Issue #1934:

That's interesting! What the new iteration is based on?

The most important part is the encoding in the binary and text formats for WebAssembly itself, as described in the explainer. See also the section on WebIDL integration in that explainer.

In the explainer, you can see snippets that include extensions to the wat text format. I've seen people call this wit, and WASI uses an extended form of it, called witx. Developer tools will probably use something along these lines to define interfaces, as described by @radu-matei in a recent blog post.

Wasmtime GitHub notifications bot (Jul 01 2020 at 18:48):

bubagl commented on Issue #1934:

Will wasmtime support "dynamic linking" (https://webassembly.org/docs/dynamic-linking) in the future?

Wasmtime GitHub notifications bot (Jul 01 2020 at 19:09):

alexcrichton commented on Issue #1934:

Wasmtime should "support" that today actually, in the sense that the dynamic linking as proposed there is purely an embedder construct building on core wasm building blocks. AFAIK C/Emscripten have at least basic support for that style of linking but I don't think that it's super widely used at this time. The module linking proposal may become a new foundation for dynamic linking.

In any case Wasmtime will support dynamic linking of wasm modules, it's mostly just a question of how exactly that will look like in the ecosystem.

Wasmtime GitHub notifications bot (Jul 02 2020 at 04:41):

bubagl commented on Issue #1934:

Wasmtime should "support" that today actually

could you point out some example of dynamic linking. I don't see dlopen implemented by WT.

Wasmtime GitHub notifications bot (Jul 02 2020 at 16:45):

alexcrichton commented on Issue #1934:

I don't currently know of any examples of dlopen and/or that scheme of dynamic linking. I believe it's mostly just a description of how it could work rather than a working system. The purpose of that explanation, however, is how it can be built on the MVP of wasm and doesn't need runtime support, so for that scheme of dynamic linking you won't find it in Wasmtime.

Last updated: Dec 23 2024 at 13:07 UTC