Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allowing Linker.define to take impl LinearMemory #2477

Closed
bkolobara opened this issue Dec 4, 2020 · 4 comments
Closed

Allowing Linker.define to take impl LinearMemory #2477

bkolobara opened this issue Dec 4, 2020 · 4 comments

Comments

@bkolobara
Copy link

Currently the Linker.define function takes an item that implements Into<Extern> and Extern takes a Memory struct.
I would like to define a structure that implements LinearMemory and pass it to the linker. Would this be possible?

@peterhuene
Copy link
Member

peterhuene commented Dec 4, 2020

Hi @bkolobara! Currently the LinearMemory trait doesn't provide enough information to properly represent a WebAssembly linear memory for importing; it's primarily missing the memory's "type" (i.e. MemoryType).

The LinearMemory trait is only intended to be used from the MemoryCreator trait and, when configured with Config::with_host_memory, that's used whenever creating a linear memory, either from instantiating a module that defines one or when you create a Memory in the host.

It would be possible to implement a Memory::new_with_creator (or similar) method that you could use to pass a MemoryCreator to use just for that specific Memory.

Before implementing that, though, does Config::with_host_memory not suit your needs? Do you need control over the way memory is allocated for a specific Memory and are okay with Wasmtime handling the allocation for any other linear memories?

@bkolobara
Copy link
Author

bkolobara commented Dec 4, 2020

Thanks for the explanation. Maybe I should provided more context, I wanted to create a memory that I could share between threads as Memory is not Send or Sync. I assume, this is something you will support in the future, but I was looking for a short term solution for testing.

@peterhuene
Copy link
Member

peterhuene commented Dec 4, 2020

A Memory isn't Send or Sync because of this general issue for instances not being Send or Sync and currently Memory stores a representation of an instance internally (a module is defined to export the memory and then is instantiated to create it).

Right now the Wasmtime API expects everything in a Store to be on the same thread. A consequence of this is that the memory.grow operation is not synchronized as only a single Instance can interact with the imported memory at a time as Instance is not Send. I can't think of any workaround solutions to this problem that would be safe to do.

This needs to change to fully support the Wasm threads proposal; for example, it should be possible to have multiple instances running on different threads import the same shared linear memory and synchronize any growth operations. However, Wasmtime doesn't support shared linear memories today.

@bkolobara
Copy link
Author

Thanks for the clarification, I will close this issue as there are others tracking the threading support.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants