Stream: wasmtime

Topic: new `Func::wrap` PR

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

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.

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

Alex Crichton (Mar 18 2020 at 19:53):

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

Alex Crichton (Mar 18 2020 at 19:53):

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

Alex Crichton (Mar 18 2020 at 19:53):

the host is the host after all

Dan Gohman (Mar 18 2020 at 19:54):

I guess that's true.

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.

Dan Gohman (Mar 18 2020 at 19:55):

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

Dan Gohman (Mar 18 2020 at 19:56):

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

Alex Crichton (Mar 18 2020 at 20:02):

that's basically my thinking yeah

Alex Crichton (Mar 18 2020 at 20:02):

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

Alex Crichton (Mar 18 2020 at 20:02):

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

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?

Dan Gohman (Mar 18 2020 at 20:15):

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

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

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 :-)

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.

Alex Crichton (Mar 18 2020 at 21:02):

@Dan Gohman oh sorry was in a mtg

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

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: Oct 23 2024 at 20:03 UTC