Stream: git-wasmtime

Topic: wasmtime / Issue #2477 Allowing Linker.define to take imp...

Wasmtime GitHub notifications bot (Dec 04 2020 at 16:30):

bkolobara opened Issue #2477:

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?

Wasmtime GitHub notifications bot (Dec 04 2020 at 18:22):

peterhuene commented on Issue #2477:

Hi @bkolobara! Currently the LinearMemory trait doesn't provide enough information to properly represent a WebAssembly linear memory for the 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?

Wasmtime GitHub notifications bot (Dec 04 2020 at 18:22):

peterhuene edited a comment on Issue #2477:

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?

Wasmtime GitHub notifications bot (Dec 04 2020 at 19:48):

bkolobara commented on Issue #2477:

Thanks for the explanation. Maybe I should provided some 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.

Wasmtime GitHub notifications bot (Dec 04 2020 at 19:49):

bkolobara edited a comment on Issue #2477:

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.

Wasmtime GitHub notifications bot (Dec 04 2020 at 21:36):

peterhuene commented on Issue #2477:

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 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.

Wasmtime GitHub notifications bot (Dec 04 2020 at 21:51):

bkolobara commented on Issue #2477:

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

Wasmtime GitHub notifications bot (Dec 04 2020 at 21:51):

bkolobara closed Issue #2477:

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?

Wasmtime GitHub notifications bot (Dec 04 2020 at 22:03):

peterhuene edited a comment on Issue #2477:

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.

Last updated: Dec 23 2024 at 13:07 UTC