Stream: git-wasmtime

Topic: wasmtime / Issue #2108 Caller get_export() implemented fo...

Wasmtime GitHub notifications bot (Aug 06 2020 at 17:37):

github-actions[bot] commented on Issue #2108:

Subscribe to Label Action

cc @peterhuene

<details>
This issue or pull request has been labeled: "wasmtime:api"

Thus the following users have been cc'd because of the following labels:

• peterhuene: wasmtime:api

To subscribe or unsubscribe from this label, edit the <code>.github/subscribe-to-label.json</code> configuration file.

Learn more.
</details>

Wasmtime GitHub notifications bot (Aug 06 2020 at 18:01):

alexcrichton commented on Issue #2108:

Thanks for the PR! Could you outline a bit the motivation for this change?

Our intention is to sort of keep the Caller type "hamstrung" for now because we don't want it to exist long-term. For now it's the only way to implement WASI APIs, but the intention is that interface types will subsume the need for this API (and we'll remove it once that's implemented and stabilized). With interface types, however, you won't have much access to the calling module's functions, so I'd be wary to enable a pretty critical piece of functionality we're inevitably going to remove.

In any case though I'm curious to hear more about your use case, since we might still be able to cater to it one way or another!

Wasmtime GitHub notifications bot (Aug 06 2020 at 18:08):

PiotrSikora commented on Issue #2108:

@alexcrichton @agiachris is working on a test framework for [Proxy-Wasm] modules (and hopefully WASI in the future), which uses Wasmtime as the runtime. See: https://github.com/proxy-wasm/test-framework/pull/1

[Proxy-Wasm]: https://github.com/proxy-wasm

Wasmtime GitHub notifications bot (Aug 06 2020 at 18:22):

PiotrSikora edited a comment on Issue #2108:

@alexcrichton @agiachris is working on a test framework for [Proxy-Wasm] modules (and hopefully WASI in the future), which uses Wasmtime as the runtime, and we needed a way for Func::wrap() hostcalls to call functions (entry points) exported from the [Proxy-Wasm] modules. See: https://github.com/proxy-wasm/test-framework/pull/1

[Proxy-Wasm]: https://github.com/proxy-wasm

Wasmtime GitHub notifications bot (Aug 06 2020 at 19:23):

alexcrichton commented on Issue #2108:

Ok thanks for the background. It looks like y'all are primarily using this to lookup the calling module's malloc function, right? If that's the case then that's something which interface types will enable so this seems reasonable to allow.

Could you also update the documentation though to leave the clause that it's only implemented for some types? Additionally can you add some words to the documentation that for functions it should in general follow the guidelines of the interface types proposal for accessing exports and calling them?

Finally, one thing I wanted to point out, y'all will want to be extremely careful when accessing the caller's memory. The main idea is that once you get a raw pointer into wasm memory you can't call wasm again because that pointer could get relocated. In https://github.com/proxy-wasm/test-framework/pull/1 the proxy_get_buffer_bytes export is an example where malloc is called while holding some pointers alive over the call to malloc. Where possible I'd recommend investigating witx and wiggle since they should make implementing all of these host calls with 100% safe code much easier.

Wasmtime GitHub notifications bot (Aug 06 2020 at 20:50):

agiachris commented on Issue #2108:

@alexcrichton thanks for the suggestion, we will make those changes. I've gone ahead and updated the documentation for the implementation only supporting specific types (Memory and Func), however I'm unfamiliar with the interface types guidelines. Could you please suggest the necessary documentation text for this?

Wasmtime GitHub notifications bot (Aug 07 2020 at 16:24):

alexcrichton commented on Issue #2108:

Thanks!

Last updated: Dec 23 2024 at 13:07 UTC