Stream: git-wasmtime

Topic: wasmtime / PR #1237 Add a first-class way of accessing ca...

Wasmtime GitHub notifications bot (Mar 05 2020 at 18:29):

alexcrichton opened PR #1237 from memory-arg to master:

This commit adds a first-class way to access a caller's memory when
defining a Func implemented by the host. This is a very common usage
scenario where the wasm module calls a host function with pointers to
its own wasm memory, and the host function needs to read that
information.

Currently, however, it's pretty roundabout to implement this
functionality in wasm. Typically you'll have to set up an
Rc<RefCell<Option<Memory>>>, close over that in your function imports,
and then fill it in once the instance is created. The goal of this PR is
to make it more ergonomic to implement this.

Note that eventually this is intended to be supplanted by interface
types which automatically and safely convert from wasm memory to host
objects. Interface types though is still aways out and it seemed like it
would be prudent to have this functionality for users today.

Currently the shape of this functionality is to allow adding an argument
to Func::wrap* closures of Option<Memory>. If available this option
will be filled in with Some of the caller's memory. This ends up
being None in a few places:

• The calling module may not actually have a memory
• There may not be a calling module in the case that you directly call
  Func::call or similar.

Note that this is also at least violating the spirit of the JS API,
since there's no equivalent to this functionality there whatsoever.
Additionally this breaks concepts of encapsulation because it means your
memory can be accessed regardless of whether it's exported or not. To
make matters even worse it has no way to cope with multi-memory, it
simply returns None if there's more than one memory defined.

Overall this is intended to be a convenience or an escape hatch. As a
host you sort of get the power to do whatever you want with the module.
Empirically there's at least one major use case of this today, WASI.
There's also been mentions on Zulip of other needs for something like
this as well. This feels like it's basically useful enough that we
should provide it today, with an eye towards deprecating it once
interface types are implemented.

Wasmtime GitHub notifications bot (Mar 05 2020 at 18:56):

alexcrichton updated PR #1237 from memory-arg to master:

This commit adds a first-class way to access a caller's memory when
defining a Func implemented by the host. This is a very common usage
scenario where the wasm module calls a host function with pointers to
its own wasm memory, and the host function needs to read that
information.

Currently, however, it's pretty roundabout to implement this
functionality in wasm. Typically you'll have to set up an
Rc<RefCell<Option<Memory>>>, close over that in your function imports,
and then fill it in once the instance is created. The goal of this PR is
to make it more ergonomic to implement this.

Note that eventually this is intended to be supplanted by interface
types which automatically and safely convert from wasm memory to host
objects. Interface types though is still aways out and it seemed like it
would be prudent to have this functionality for users today.

Currently the shape of this functionality is to allow adding an argument
to Func::wrap* closures of Option<Memory>. If available this option
will be filled in with Some of the caller's memory. This ends up
being None in a few places:

• The calling module may not actually have a memory
• There may not be a calling module in the case that you directly call
  Func::call or similar.

Note that this is also at least violating the spirit of the JS API,
since there's no equivalent to this functionality there whatsoever.
Additionally this breaks concepts of encapsulation because it means your
memory can be accessed regardless of whether it's exported or not. To
make matters even worse it has no way to cope with multi-memory, it
simply returns None if there's more than one memory defined.

Overall this is intended to be a convenience or an escape hatch. As a
host you sort of get the power to do whatever you want with the module.
Empirically there's at least one major use case of this today, WASI.
There's also been mentions on Zulip of other needs for something like
this as well. This feels like it's basically useful enough that we
should provide it today, with an eye towards deprecating it once
interface types are implemented.

Wasmtime GitHub notifications bot (Mar 11 2020 at 14:50):

alexcrichton closed without merge PR #1237.

Last updated: Dec 23 2024 at 13:07 UTC