Stream: wasmtime

Topic: new `Func::wrap` PR


view this post on Zulip Alex Crichton (Mar 18 2020 at 19:45):

@Dan Gohman did you want to yourself review https://github.com/bytecodealliance/wasmtime/pull/1290? I'm curious to tweak the APIs a bit more and it'd be building on top of that work so was pondering who to poke for a review

This commit is a continuation of #1237 and updates the API of Func to allow defining host functions which have easy access to a caller's memory in particular. The new APIs look like so: The Fu...

view this post on Zulip Dan Gohman (Mar 18 2020 at 19:52):

@Alex Crichton I haven't yet decided what I think about this. Using the caller vmctx is cleaner than the mechanism we had before, but as we add more support for controlling how imports and exports are resolved at link time, this will be a kind of back door around that, allowing a process to access exports that haven't been linked with its imports.

view this post on Zulip Alex Crichton (Mar 18 2020 at 19:53):

@Dan Gohman it's true yeah, but we need something today for wasi at the very least

view this post on Zulip Alex Crichton (Mar 18 2020 at 19:53):

and it's not like this is set in stone forever, we can always remove it

view this post on Zulip Alex Crichton (Mar 18 2020 at 19:53):

I also personally feel that if the host can subvert things that's ok

view this post on Zulip Alex Crichton (Mar 18 2020 at 19:53):

the host is the host after all

view this post on Zulip Dan Gohman (Mar 18 2020 at 19:54):

I guess that's true.

view this post on Zulip Dan Gohman (Mar 18 2020 at 19:55):

I'm trying to minimize differences between host modules and wasm modules in my mental model, because we want them to be interchangeable.

view this post on Zulip Dan Gohman (Mar 18 2020 at 19:55):

But, wasi does need this special power, as will other wasi-like modules

view this post on Zulip Dan Gohman (Mar 18 2020 at 19:56):

At least, until interface types gives us a better way to pass views of memory around.

view this post on Zulip Alex Crichton (Mar 18 2020 at 20:02):

that's basically my thinking yeah

view this post on Zulip Alex Crichton (Mar 18 2020 at 20:02):

we want to erase this, but... we sort of can't right now

view this post on Zulip Alex Crichton (Mar 18 2020 at 20:02):

and we may as well make it convenient b/c it's gonna be mega-common

view this post on Zulip Dan Gohman (Mar 18 2020 at 20:15):

How crazy would it be to say you can't use Caller on a module that uses interface types?

view this post on Zulip Dan Gohman (Mar 18 2020 at 20:15):

I.e., dynamically enforce that, and document it that way.

view this post on Zulip Dan Gohman (Mar 18 2020 at 20:18):

I'm not sure if that's the right answer, but I'm thinking about ways we can avoid mega-common + convenient = too widely used to be removed

view this post on Zulip Dan Gohman (Mar 18 2020 at 20:30):

Lol, I was just thinking "what if we restricted it to just memory exports", and then read the code for get_export, and that's exactly what it does :-)

view this post on Zulip Dan Gohman (Mar 18 2020 at 20:48):

@Alex Crichton Ok, I convinced myself that we don't need to add arbitrary restrictions like that. When interface types are ready, we'll just have toolchains use them, and have them stop exporting "memory" by default as they do now, and that will steer people in the right direction.

view this post on Zulip Alex Crichton (Mar 18 2020 at 21:02):

@Dan Gohman oh sorry was in a mtg

view this post on Zulip Alex Crichton (Mar 18 2020 at 21:02):

but yeah I think we could easily make get_export return None if it's an interface types module

view this post on Zulip Alex Crichton (Mar 18 2020 at 21:02):

but if it only works on exports the toolchains could also fix it with no exports


Last updated: Dec 23 2024 at 13:07 UTC