more ergonomic host/wasm communication · wasmtime

that's the longer-term vision for how host-wasm communication will be nicer (and it'll abstract all the details of memory growth, string allocations, your slice structures, etc)

Alex Crichton (Feb 18 2021 at 19:02):

and yeah this is why we're pushing towards a longer-term vision b/c getting it all right today is not easy

Yehuda Katz (Feb 18 2021 at 19:02):

Alex Crichton said:

yeah so our general answer to this is interface types

for my use-case it's really important that whatever I do can easily work both in wasmtime and on the web

Yehuda Katz (Feb 18 2021 at 19:02):

so I'm willing to do more work to wire it up if necessary

Alex Crichton (Feb 18 2021 at 19:03):

long-term that'll all be in place yeah

Alex Crichton (Feb 18 2021 at 19:03):

interface types was actually originally created for web host apis

Yehuda Katz (Feb 18 2021 at 19:03):

what are the challenges with higher-level APIs for moving blobs of bytes around?

Yehuda Katz (Feb 18 2021 at 19:03):

yeah I know

Yehuda Katz (Feb 18 2021 at 19:03):

I'm a little weirded out by the fact that they're conceptually coupled to wasm-gc, fwiw

Alex Crichton (Feb 18 2021 at 19:03):

oh it's mostly just standardization

Yehuda Katz (Feb 18 2021 at 19:04):

Rust teaches us that interface types and GC have nothing to do with each other :P

Alex Crichton (Feb 18 2021 at 19:04):

like just finding the right way to express all this in wasm and standardize it

Yehuda Katz (Feb 18 2021 at 19:04):

it's not quite just standardization

Yehuda Katz (Feb 18 2021 at 19:04):

but yeah I get it :)

Yehuda Katz (Feb 18 2021 at 19:04):

I noticed all of this because I was working on the interaction between the JS typed objects proposal and wasm

Yehuda Katz (Feb 18 2021 at 19:04):

and it really was "integration with wasm-gc" which seemed weird to me as a Rust person

Alex Crichton (Feb 18 2021 at 19:05):

the problem with interface types right now it's that it's a very long-term vision and we've not made a ton of progress in making it a closer reality

Yehuda Katz (Feb 18 2021 at 19:05):

yep

Alex Crichton (Feb 18 2021 at 19:05):

that's something we're starting to make progress on, however

Alex Crichton (Feb 18 2021 at 19:05):

fitzgen/I are working on the next step towards interface types and such

Alex Crichton (Feb 18 2021 at 19:05):

and I just recently finished one half of it

Yehuda Katz (Feb 18 2021 at 19:05):

personally, I wish interface types were just separated into their own proposal, but that's so far above my pay grade :)

Yehuda Katz (Feb 18 2021 at 19:05):

excellent

Yehuda Katz (Feb 18 2021 at 19:06):

what would you say is the correct pattern for moving around Vec<u8> today?

Alex Crichton (Feb 18 2021 at 19:06):

it's also worth pointing out that interface types is somewhat nebulous

Alex Crichton (Feb 18 2021 at 19:06):

the long-term vision is aligned with everyone I think

Yehuda Katz (Feb 18 2021 at 19:06):

this is what I was trying to do: https://github.com/wycats/wand/blob/main/crates/wand-cli/src/slice.rs

wycats/wand

Contribute to wycats/wand development by creating an account on GitHub.

Alex Crichton (Feb 18 2021 at 19:06):

but there's a lot of various mid-states that are very worthwhile and useful before we get to the long-term part

Alex Crichton (Feb 18 2021 at 19:06):

so for example a great "mvp" of interface types probably doesn't need wasm-gc

Alex Crichton (Feb 18 2021 at 19:06):

(e.g. what fitzgen/I are working on)

Yehuda Katz (Feb 18 2021 at 19:07):

Alex Crichton said:

the long-term vision is aligned with everyone I think

as an aside, I think wasm has been most effective when the scope has been:

fairly well-specified and understood by everyone
very well-motivated by web use-cases

but that's my personal opinion :)

Alex Crichton (Feb 18 2021 at 19:07):

agreed yeah

Yehuda Katz (Feb 18 2021 at 19:08):

Alex Crichton said:

so for example a great "mvp" of interface types probably doesn't need wasm-gc

it seems like, at minimum, the equivalent of Rust Copy types should be doable as an MVP

Alex Crichton (Feb 18 2021 at 19:08):

right yeah

Yehuda Katz (Feb 18 2021 at 19:08):

when I bring up Copy to non-Rust people, it's just not a category they know how to wrap their heads around

Alex Crichton (Feb 18 2021 at 19:08):

for getting something done today what you've got there is a good start, the missing pieces would be safety/error handling as well as dealing with malloc/free

Yehuda Katz (Feb 18 2021 at 19:08):

yeah

Alex Crichton (Feb 18 2021 at 19:08):

e.g. if you want to pass a string to wasm you need to malloc space for it

Yehuda Katz (Feb 18 2021 at 19:08):

basically I don't know how to think about safety

Alex Crichton (Feb 18 2021 at 19:08):

or if wasm returns a string you may need to free it

Alex Crichton (Feb 18 2021 at 19:09):

but so you said you've heard of wiggle?

Yehuda Katz (Feb 18 2021 at 19:09):

https://github.com/wycats/wand/blob/main/crates/wand-cli/src/main.rs#L31

wycats/wand

Contribute to wycats/wand development by creating an account on GitHub.

Yehuda Katz (Feb 18 2021 at 19:09):

this is the other half of it

Yehuda Katz (Feb 18 2021 at 19:09):

I've heard of wiggle but haven't looked into it much

Alex Crichton (Feb 18 2021 at 19:09):

ah right yeah

Alex Crichton (Feb 18 2021 at 19:09):

lemme get some links for you

Yehuda Katz (Feb 18 2021 at 19:09):

that link is where I'm confident I'm messing up :P

Yehuda Katz (Feb 18 2021 at 19:09):

@Alex Crichton the good news about Rust is that most things have rustdoc. The bad news is that many things only have Rustdoc :P

Alex Crichton (Feb 18 2021 at 19:10):

it's true :(

Alex Crichton (Feb 18 2021 at 19:10):

we could alway benefit from more examples

Yehuda Katz (Feb 18 2021 at 19:10):

it's ok ;)

Alex Crichton (Feb 18 2021 at 19:10):

so the purpose of wiggle is to make integration with *.witx files easier

Yehuda Katz (Feb 18 2021 at 19:10):

I'm always happy to help with docs on things I'm working on

Yehuda Katz (Feb 18 2021 at 19:10):

and write decently fast

Yehuda Katz (Feb 18 2021 at 19:10):

but I need to understand first

Alex Crichton (Feb 18 2021 at 19:10):

so for example WASI is specified with *.witx

Alex Crichton (Feb 18 2021 at 19:10):

e.g. -- https://github.com/WebAssembly/WASI/blob/ef8c1a53feb2dfb763d4ea5c7d9e0a0126b45579/phases/snapshot/witx/wasi_snapshot_preview1.witx#L282-L289

WebAssembly/WASI

WebAssembly System Interface. Contribute to WebAssembly/WASI development by creating an account on GitHub.

Alex Crichton (Feb 18 2021 at 19:11):

which is a high-level description of an API

Alex Crichton (Feb 18 2021 at 19:11):

as you can see takes a string and returns a Result

Alex Crichton (Feb 18 2021 at 19:11):

what wiggle does is it allows you to hook that up automatically to a host implementation -- https://github.com/bytecodealliance/wasmtime/blob/aed6de32d4e5603a7f85619d84099a9a05cb7a7c/crates/wasi-common/src/snapshots/preview_1.rs#L687-L696

bytecodealliance/wasmtime

Standalone JIT-style runtime for WebAssembly, using Cranelift - bytecodealliance/wasmtime

Alex Crichton (Feb 18 2021 at 19:11):

which as you can see is all safe

Alex Crichton (Feb 18 2021 at 19:12):

wiggle does all the "ABI goop" of bounds checks, errors, etc

Alex Crichton (Feb 18 2021 at 19:12):

so you only write in 100% safe rust

Alex Crichton (Feb 18 2021 at 19:12):

this is the theory behind wiggle

Alex Crichton (Feb 18 2021 at 19:12):

it's still kind of boiler-plate-y to get all this hooked up

Alex Crichton (Feb 18 2021 at 19:12):

and is something we're continuing to improve

Yehuda Katz (Feb 18 2021 at 19:12):

@Alex Crichton I think one of the things I would benefit from the most is just a sense of what things are stable

Alex Crichton (Feb 18 2021 at 19:12):

but that's the general idea of where our end-state will be

Yehuda Katz (Feb 18 2021 at 19:13):

@Alex Crichton oh, another random topic

Yehuda Katz (Feb 18 2021 at 19:13):

not that random :P

Yehuda Katz (Feb 18 2021 at 19:13):

I was wondering if folks are thinking that wasi should integrate with stuff like the JS FileSystem API

Yehuda Katz (Feb 18 2021 at 19:13):

I asked Aaron about it and he didn't know

Yehuda Katz (Feb 18 2021 at 19:13):

but I was a little surprised it didn't do that

Yehuda Katz (Feb 18 2021 at 19:14):

(and also, how wasi would handle the need to get permissions in the first place)

Alex Crichton (Feb 18 2021 at 19:14):

wasi currently focuses mainly on non-web applications of wasm

Alex Crichton (Feb 18 2021 at 19:14):

it's always been expected, however, that a web port is possible

Alex Crichton (Feb 18 2021 at 19:14):

but there's not currently an official "here's the wasi api for the web" implementation

Alex Crichton (Feb 18 2021 at 19:14):

and afaik posix has more of an effect on the design than the web

Alex Crichton (Feb 18 2021 at 19:14):

(I'm totally unfamiliar with the filesystem api myself)

Yehuda Katz (Feb 18 2021 at 19:16):

Alex Crichton said:

wasi currently focuses mainly on non-web applications of wasm

see my earlier thought about wasm scope

Yehuda Katz (Feb 18 2021 at 19:16):

;)

Yehuda Katz (Feb 18 2021 at 19:16):

https://rustwasm.github.io/wasm-bindgen/api/web_sys/struct.FileSystem.html

Alex Crichton (Feb 18 2021 at 19:17):

in any case today everything about this, especially crossing js/host embeddings, is going to be pretty manual

Alex Crichton (Feb 18 2021 at 19:18):

e.g. you're going to be writing very similar glue code in both Rust and in JS

Alex Crichton (Feb 18 2021 at 19:18):

that's what's currently available, and in the future we hope to provide tools to make this much easier, basically auto-generating both the JS and the Rust code based on the desired interface of the module

Alex Crichton (Feb 18 2021 at 19:18):

like you export a function that takes/returns a string and we'd auto-generate the JS glue and the Rust glue for doing that

Alex Crichton (Feb 18 2021 at 19:19):

no need to manage WasmSlice yourself

Yehuda Katz (Feb 18 2021 at 19:22):

I don't mind writing a lot of the glue code myself

Yehuda Katz (Feb 18 2021 at 19:22):

I am expecting to need to manually write two hosts

Yehuda Katz (Feb 18 2021 at 19:22):

wasmtime and web

Yehuda Katz (Feb 18 2021 at 19:22):

but I don't want to be forced into assuming a JS client

Yehuda Katz (Feb 18 2021 at 19:23):

I'm literally using wasm-pack right now because it's the best way to run the steps

Yehuda Katz (Feb 18 2021 at 19:23):

and then I literally copy the .wasm

Alex Crichton (Feb 18 2021 at 19:24):

another aspect which may also be possible is to have two wasm blobs, one using wasm-bindgen for the web and one using handwritten stuff for wasmtime

Alex Crichton (Feb 18 2021 at 19:24):

that would at least relinquish you from having to write js glue code

Yehuda Katz (Feb 18 2021 at 19:24):

but they can't have a single set of externs

Yehuda Katz (Feb 18 2021 at 19:25):

what's slightly frustrating is that there's not a good story for "how to interact manually with the .wasm file created by wasm-bindgen"

Yehuda Katz (Feb 18 2021 at 19:25):

it kind of feels like there should be a Rust API for calling a wasm_bindgen function that takes a String that doesn't have much to do with JS

Alex Crichton (Feb 18 2021 at 19:25):

true, the wasm-bindgen ABI is unstable and not really documented

Yehuda Katz (Feb 18 2021 at 19:25):

is that intentional, or just path dependence?

Yehuda Katz (Feb 18 2021 at 19:25):

I would be happy to help :)

Alex Crichton (Feb 18 2021 at 19:25):

that's totally possible, but it breaks down very quickly

Alex Crichton (Feb 18 2021 at 19:26):

there's just way too much in wasm-bindgen that assumes JS

Yehuda Katz (Feb 18 2021 at 19:26):

presumably there's some need for a somewhat stable answer in order for the JS side to work?

Yehuda Katz (Feb 18 2021 at 19:26):

right

Alex Crichton (Feb 18 2021 at 19:26):

once you start only talking about structs and strings what you're actually talking about is interface types

Yehuda Katz (Feb 18 2021 at 19:26):

would it be possible to break out wasm_bindgen_core and wasm_bindgen_js?

Alex Crichton (Feb 18 2021 at 19:26):

I've toyed with the idea of this in the past

Alex Crichton (Feb 18 2021 at 19:26):

the tl;dr; is basically "no"

Alex Crichton (Feb 18 2021 at 19:26):

or rather, it's possible, but you're just doing interface types

Alex Crichton (Feb 18 2021 at 19:27):

I plan to, one day, rebuild wasm-bindgen on interface types

Alex Crichton (Feb 18 2021 at 19:27):

but interface types needs to make more progress in the meantime naturally

Yehuda Katz (Feb 18 2021 at 19:31):

why wouldn't the rough interning strategy for JS work more generally?

Yehuda Katz (Feb 18 2021 at 19:31):

half the battle of wasm_bindgen is inside of Rust, right?

Yehuda Katz (Feb 18 2021 at 19:32):

why isn't that stuff fully applicable to non-JS clients?

Alex Crichton (Feb 18 2021 at 19:32):

oh it is

Alex Crichton (Feb 18 2021 at 19:32):

if you touch just the right set of things you could write a native side of wasm-bindgen

Alex Crichton (Feb 18 2021 at 19:32):

like you could just translate the JS glue code to Rust

Alex Crichton (Feb 18 2021 at 19:32):

there's no fundamental reason that can't be done

Alex Crichton (Feb 18 2021 at 19:33):

there's practical reasons for why I haven't done that though

Yehuda Katz (Feb 18 2021 at 19:33):

yeah that makes sense

Yehuda Katz (Feb 18 2021 at 19:34):

Alex Crichton said:

another aspect which may also be possible is to have two wasm blobs, one using wasm-bindgen for the web and one using handwritten stuff for wasmtime

I'm trying to work out what exactly it would mean to do this

Yehuda Katz (Feb 18 2021 at 19:34):

I could create two totally different sets of extern functions

Yehuda Katz (Feb 18 2021 at 19:34):

but it feels like it'll just be the same thing twice with slightly different low-level protocols

Alex Crichton (Feb 18 2021 at 19:34):

yeah that's' what i'm imagining

Alex Crichton (Feb 18 2021 at 19:34):

basically

Yehuda Katz (Feb 18 2021 at 19:34):

ok, next question

Yehuda Katz (Feb 18 2021 at 19:34):

how do I learn wiggle?

Alex Crichton (Feb 18 2021 at 19:34):

all the "meat" would be a shared rust dep

Alex Crichton (Feb 18 2021 at 19:34):

wiggle is only intended for wasm-to-host communication at this time

Yehuda Katz (Feb 18 2021 at 19:35):

Alex Crichton (Feb 18 2021 at 19:35):

so while it's the right shape of what you want I don't think it's entirely waht you want

Alex Crichton (Feb 18 2021 at 19:35):

b/c you also want "enriched" host-to-wasm communication

Yehuda Katz (Feb 18 2021 at 19:35):

I'm basically used to the JS story of just transferring very basic bytes

Yehuda Katz (Feb 18 2021 at 19:35):

and I don't mind having to do that

Yehuda Katz (Feb 18 2021 at 19:35):

but even that felt like a song and dance

Yehuda Katz (Feb 18 2021 at 19:35):

I could build WasmString on top of WasmSlice very easily, obviously

Yehuda Katz (Feb 18 2021 at 19:35):

I guess what I'm saying is I want WasmSlice in wasmtime :P

Yehuda Katz (Feb 18 2021 at 19:35):

in addition to Memory

Yehuda Katz (Feb 18 2021 at 19:36):

at the limit, I can just transmute the hell out of things

Alex Crichton (Feb 18 2021 at 19:36):

The new Memory::read API is close I think to what you might want

Alex Crichton (Feb 18 2021 at 19:37):

perhaps coupled with another Memory::read_vec, Memory::read_string, and Memory::read_str

Yehuda Katz (Feb 18 2021 at 19:37):

right

Yehuda Katz (Feb 18 2021 at 19:37):

which would require a tiny ABI

Yehuda Katz (Feb 18 2021 at 19:37):

basically len/ptr

Alex Crichton (Feb 18 2021 at 19:37):

it also kinda sucks that Rust can't do multi-value easily

Alex Crichton (Feb 18 2021 at 19:38):

like you want to write a wasm function that retuns two i32

Alex Crichton (Feb 18 2021 at 19:38):

instead of a packed i64

Alex Crichton (Feb 18 2021 at 19:38):

but Rust won't let you do that

Yehuda Katz (Feb 18 2021 at 19:38):

can't you just use a tuple?

Yehuda Katz (Feb 18 2021 at 19:38):

I guess I don't know the wasm abi for multi-value

Yehuda Katz (Feb 18 2021 at 19:38):

I guess you can just do read() and carefully make sure to make a Vec with the right capacity?

Yehuda Katz (Feb 18 2021 at 19:39):

it seems like read() is a bit of a rube goldberg machine for reading a certain amount of bytes

Yehuda Katz (Feb 18 2021 at 19:39):

first make a Vec with the right capacity

Yehuda Katz (Feb 18 2021 at 19:39):

well

Yehuda Katz (Feb 18 2021 at 19:39):

first read a u32

Yehuda Katz (Feb 18 2021 at 19:39):

then make a Vec::with_capacity(that size)

Yehuda Katz (Feb 18 2021 at 19:39):

then advance the ptr

Yehuda Katz (Feb 18 2021 at 19:39):

(by 4)

Yehuda Katz (Feb 18 2021 at 19:39):

then read()

Alex Crichton (Feb 18 2021 at 19:39):

yeah that's what I mean with read_vec in addition to the read that we have today

Yehuda Katz (Feb 18 2021 at 19:39):

yeah

Alex Crichton (Feb 18 2021 at 19:40):

like you should be able to do memory.read(ptr..ptr+len)

Yehuda Katz (Feb 18 2021 at 19:40):

yeah

Alex Crichton (Feb 18 2021 at 19:40):

and it allocates the Vec for you and all that

Yehuda Katz (Feb 18 2021 at 19:40):

it does?

Alex Crichton (Feb 18 2021 at 19:40):

no I mean we should have an API that does that

Yehuda Katz (Feb 18 2021 at 19:40):

oh you're saying read_vec

Yehuda Katz (Feb 18 2021 at 19:40):

yeah

Alex Crichton (Feb 18 2021 at 19:40):

oh sorry yeah

Yehuda Katz (Feb 18 2021 at 19:40):

like I said it would require an ABI

Yehuda Katz (Feb 18 2021 at 19:40):

which is a bit "new" to this API

Yehuda Katz (Feb 18 2021 at 19:40):

how does wasm_bindgen do it?

Alex Crichton (Feb 18 2021 at 19:41):

hm you may need to be more precise

Alex Crichton (Feb 18 2021 at 19:41):

do you mean like how does wasm-bindgen return a string from wasm to JS?

Yehuda Katz (Feb 18 2021 at 19:42):

yeah

Yehuda Katz (Feb 18 2021 at 19:42):

what's the protocol?

Yehuda Katz (Feb 18 2021 at 19:42):

I've seen people try to reverse engineer the ABI in various threads

Yehuda Katz (Feb 18 2021 at 19:42):

but it seemed crazy :P

Alex Crichton (Feb 18 2021 at 19:42):

it's funky -- first 8 bytes of the shadow stack is reserved, and that return pointer is passed as the first parameter

Alex Crichton (Feb 18 2021 at 19:43):

then when the call finishes the 8 bytes are interpreted as ptr/len

Alex Crichton (Feb 18 2021 at 19:43):

the ptr/len are then copied out and decoded as utf-8

Alex Crichton (Feb 18 2021 at 19:43):

then the ptr/len are freed

Yehuda Katz (Feb 18 2021 at 19:43):

Alex Crichton said:

it's funky -- first 8 bytes of the shadow stack is reserved, and that return pointer is passed as the first parameter

is it really that crazy to make an API for the low-level details like the shadow stack?

Yehuda Katz (Feb 18 2021 at 19:43):

it must already be encapsulated for maintenance reasons

Alex Crichton (Feb 18 2021 at 19:44):

not sure what you mean by encapsulated

Alex Crichton (Feb 18 2021 at 19:44):

but this is indeed something we could expose an API for

Alex Crichton (Feb 18 2021 at 19:44):

it's in a shaky realm though b/c we're just guessing what global is actually the shadow stack pointer, if any

Yehuda Katz (Feb 18 2021 at 19:44):

I just mean it must not be a bunch of spaghetti code strewn around

Yehuda Katz (Feb 18 2021 at 19:44):

otherwise you'd keep breaking the codegen :P

Alex Crichton (Feb 18 2021 at 19:44):

most wasm modules don't even export the shadow stack pointer

Alex Crichton (Feb 18 2021 at 19:44):

you mean like in wasm-bindgen?

Yehuda Katz (Feb 18 2021 at 19:44):

I think it's ok to say "your client must do XXX YYY ZZZ and your wasm module must expose AAA BBB CCC"

Yehuda Katz (Feb 18 2021 at 19:44):

right

Yehuda Katz (Feb 18 2021 at 19:45):

I literally used wasm-bindgen + wasm-objdump and it's not THAT crazy

Yehuda Katz (Feb 18 2021 at 19:45):

but eventually I was like "this is too hard" and implemented WasmSlice

Alex Crichton (Feb 18 2021 at 19:45):

wasm-bindgen is a bit more powerful here in that it has complete control over the .wasm output iteslf

Alex Crichton (Feb 18 2021 at 19:45):

e.g. wasm-bindgen injects functions to manipulate the stack pointer

Alex Crichton (Feb 18 2021 at 19:45):

b/c they're not natively present in the wasm file

Yehuda Katz (Feb 18 2021 at 19:45):

but those functions are totally decoupled from the details of a JS client, right?

Alex Crichton (Feb 18 2021 at 19:45):

wasm-bindgen also just makes blind guesses as to what global is the stack pointer

Yehuda Katz (Feb 18 2021 at 19:46):

lol

Yehuda Katz (Feb 18 2021 at 19:46):

I mean "memory" being the magical memory name is also a protocol ;)

Alex Crichton (Feb 18 2021 at 19:46):

oh I see, yes, what you mean about taking the exact output of wasm-bindgen and feeding it into rust

Yehuda Katz (Feb 18 2021 at 19:46):

I was looking at the code myself, but at some point I don't work on the codebase and I hit some walls

Yehuda Katz (Feb 18 2021 at 19:46):

but at a conceptual level it seems like it ought to work

Yehuda Katz (Feb 18 2021 at 19:46):

I can see why interface types takes up the mental oxygen, though

Alex Crichton (Feb 18 2021 at 19:47):

oh yeah there's nothing stopping you from doing that

Alex Crichton (Feb 18 2021 at 19:47):

like it's very plausible to add a "rust" output to wasm-bindgen

Alex Crichton (Feb 18 2021 at 19:47):

where instead of spitting out *.wasm + *.js it spits out *.wasm + *.rs

Yehuda Katz (Feb 18 2021 at 19:47):

I think the use-case of "something that works with both a Rust client and a JS client" is good enough motivation, right?

Yehuda Katz (Feb 18 2021 at 19:47):

right exactly

Yehuda Katz (Feb 18 2021 at 19:47):

bingo

Yehuda Katz (Feb 18 2021 at 19:47):

that's exactly what I mean

Alex Crichton (Feb 18 2021 at 19:47):

but this is what I mentioned earlier where it breaks down fairly quickly

Alex Crichton (Feb 18 2021 at 19:47):

the main downside is it occupies the same space as interface types

Alex Crichton (Feb 18 2021 at 19:48):

and wasm-bindgen is entirely Rust-specific

Yehuda Katz (Feb 18 2021 at 19:48):

but interface types won't work on the web without wasm-gc

Alex Crichton (Feb 18 2021 at 19:48):

it also breaks down quickly once the *.rs needs to do something js-specific

Alex Crichton (Feb 18 2021 at 19:48):

like you have a Rust function taking &JsValue as an argument

Yehuda Katz (Feb 18 2021 at 19:48):

that's what I was thinking re: wasm_bindgen_core

Yehuda Katz (Feb 18 2021 at 19:48):

break out the non-JS parts of the protocol

Alex Crichton (Feb 18 2021 at 19:48):

this is what I meant about multiple phases or interim-periods of interface types

Yehuda Katz (Feb 18 2021 at 19:49):

and you're limited to that if you want a truly portable .wasm

Yehuda Katz (Feb 18 2021 at 19:49):

yeah

Alex Crichton (Feb 18 2021 at 19:49):

so like today the rust compiler spits out a *.wasm when you compile it and use wasm-bindgen

Alex Crichton (Feb 18 2021 at 19:49):

that *.wasm has a whole bunch of weird wasm-bindgen-specific stuff

Alex Crichton (Feb 18 2021 at 19:49):

imagine instead it spits out a *.wasm that's a standard wasm module using interface types

Alex Crichton (Feb 18 2021 at 19:49):

you can then natively consume that *.wasm in wasmtime (since it's standard)

Yehuda Katz (Feb 18 2021 at 19:49):

yeah

Yehuda Katz (Feb 18 2021 at 19:49):

yeah

Alex Crichton (Feb 18 2021 at 19:49):

and you can also run a tool to polyfill interface types for the web

Alex Crichton (Feb 18 2021 at 19:50):

basically exactly what wasm-bindgen does today, except based on the standard

Yehuda Katz (Feb 18 2021 at 19:50):

Alex Crichton said:

you can then natively consume that *.wasm in wasmtime (since it's standard)

as soon as wasmtime actually supports interface types

Alex Crichton (Feb 18 2021 at 19:50):

you could imagine a polyfill even for wasmtime in the meantime

Yehuda Katz (Feb 18 2021 at 19:50):

according to the issue tracker, the answer to that is ... some time in the future?

Yehuda Katz (Feb 18 2021 at 19:50):

yeah

Yehuda Katz (Feb 18 2021 at 19:50):

I don't know how to write it tho :P

Yehuda Katz (Feb 18 2021 at 19:50):

I like the idea of using interface types as a meta-language for this

Alex Crichton (Feb 18 2021 at 19:50):

correct yeah, this is basically going to happen but takes a lot of planning

Yehuda Katz (Feb 18 2021 at 19:50):

that can then be turned into the glue layer without needing Rust-specific logic

Alex Crichton (Feb 18 2021 at 19:50):

we're inching forward but there's a lot of moving pieces and we also have to prioritize with work stuff

Yehuda Katz (Feb 18 2021 at 19:50):

I think that's what Luke pitched to me 3 years ago :P

Yehuda Katz (Feb 18 2021 at 19:51):

I think for now, I don't mind going down the "two extern functions path"

Yehuda Katz (Feb 18 2021 at 19:51):

as long as I feel confident about the safety properties

Yehuda Katz (Feb 18 2021 at 19:51):

.read() is good

Alex Crichton (Feb 18 2021 at 19:52):

more APIs on Memory should be able to give you the safety guarantee

Alex Crichton (Feb 18 2021 at 19:52):

I feel you on the 3 years part though

Alex Crichton (Feb 18 2021 at 19:52):

this is the part where standards are... hard

Alex Crichton (Feb 18 2021 at 19:52):

like wasm-bindgen was easy b/c we could do whatever we wanted

Yehuda Katz (Feb 18 2021 at 19:52):

yeah

Alex Crichton (Feb 18 2021 at 19:53):

but with interface types it's different b/c we're trying to design a system that lasts

Yehuda Katz (Feb 18 2021 at 19:54):

I think it makes sense to think about the web as a locus of standards control, imo

Yehuda Katz (Feb 18 2021 at 19:54):

the web is the forcing function

Yehuda Katz (Feb 18 2021 at 19:55):

if the entire theory of an API is based on a place where people can theoretically compete with the standard, it makes everything take 10x longer

Yehuda Katz (Feb 18 2021 at 19:55):

if not more :P

Alex Crichton (Feb 18 2021 at 19:56):

heh true

Yehuda Katz (Feb 18 2021 at 19:57):

I don't have a very clear sense of how the people who are working on wasi think about wasi

Yehuda Katz (Feb 18 2021 at 19:58):

I know how to think of wasm of course

Yehuda Katz (Feb 18 2021 at 19:58):

ok, so it seems like my next steps ought to be:

Yehuda Katz (Feb 18 2021 at 19:58):

wrap memory.read() to make WasmSlice simpler

Yehuda Katz (Feb 18 2021 at 19:58):

propose read_vec and read_str (or reply to an issue if you open it first)

Yehuda Katz (Feb 18 2021 at 19:59):

discuss/learn the wasm_bindgen protocol, so next time I want to talk about future directions I know enough to be useful

Alex Crichton (Feb 18 2021 at 19:59):

yeah that sounds good

Alex Crichton (Feb 18 2021 at 19:59):

I'm making a PR for some more read_* methods soon

Yehuda Katz (Feb 18 2021 at 20:00):

I think I need to understand the song-and-dance with relation to freeing memory communicated through Memory

Yehuda Katz (Feb 18 2021 at 20:02):

I assume that to a first approximation, & borrows give you what you need

Yehuda Katz (Feb 18 2021 at 20:04):

Yehuda Katz said:

I assume that to a first approximation, & borrows give you what you need

trying to figure out what the right place to put the wrapper that could borrow out of Memory

Alex Crichton (Feb 18 2021 at 20:04):

in general for safety you'll want to avoid borrowing Memory "for a long time"

Yehuda Katz (Feb 18 2021 at 20:04):

right

Alex Crichton (Feb 18 2021 at 20:04):

you'll typically want to copy out

Yehuda Katz (Feb 18 2021 at 20:04):

I already have a wrapper around Module

Yehuda Katz (Feb 18 2021 at 20:04):

I could put read_vec in there

Yehuda Katz (Feb 18 2021 at 20:05):

the real question is:

Yehuda Katz (Feb 18 2021 at 20:05):

    let mem = module.memory();
    let len = source.len() as u32;
    let ptr: u32 = module.call1("allocate", len as u32).unwrap();
    let slice = mem.data_ptr();

    let zero = unsafe { slice.offset(ptr as isize) };

    unsafe { zero.copy_from(source.as_ptr(), source.len()) };

    // slice[ptr] = len;
    module.call2("hello", ptr, source.len() as u32)?;

Yehuda Katz (Feb 18 2021 at 20:05):

is this song-and-dance actually legit?

Alex Crichton (Feb 18 2021 at 20:06):

I would recommend using memory.write(ptr as usize, &source).unwrap(), but yes

Yehuda Katz (Feb 18 2021 at 20:07):

I saw some comments about the stability of offsets, but I'm not actually casting anything into actual pointers

Yehuda Katz (Feb 18 2021 at 20:07):

but is it possible for ptr to move?

Yehuda Katz (Feb 18 2021 at 20:07):

also: should I be calling grow() somewhere?

Yehuda Katz (Feb 18 2021 at 20:07):

do I need to drop() something somewhere?

Alex Crichton (Feb 18 2021 at 20:08):

so ptr cannot move because it is relative to the memory base

Alex Crichton (Feb 18 2021 at 20:08):

slice can move due to memory.grow

Alex Crichton (Feb 18 2021 at 20:08):

you do not need to memory.grow because allocate will do that internally if necessary

Yehuda Katz (Feb 18 2021 at 20:09):

is the allocate song-and-dance roughly correct?

Yehuda Katz (Feb 18 2021 at 20:09):

TLDR make an allocate function in the WASM Rust

Alex Crichton (Feb 18 2021 at 20:09):

yes

Yehuda Katz (Feb 18 2021 at 20:09):

call it

Yehuda Katz (Feb 18 2021 at 20:09):

get a ptr

Yehuda Katz (Feb 18 2021 at 20:09):

is it correct to cast to u32?

Alex Crichton (Feb 18 2021 at 20:10):

yes

Yehuda Katz (Feb 18 2021 at 20:10):

I'm assuming wasm32, which seems like it should be fine

Yehuda Katz (Feb 18 2021 at 20:10):

phew

Alex Crichton (Feb 18 2021 at 20:10):

well allocate will have an exact signature

Alex Crichton (Feb 18 2021 at 20:10):

and it'll probably return an i32

Alex Crichton (Feb 18 2021 at 20:10):

so if you say i64 then your rust code will just fail at runtime saying the signatures mismatch

Yehuda Katz (Feb 18 2021 at 20:10):

Alex Crichton said:

slice can move due to memory.grow

so just make sure to use it "now"?

Yehuda Katz (Feb 18 2021 at 20:10):

i.e. make it ~ &?

Alex Crichton (Feb 18 2021 at 20:10):

yep

Yehuda Katz (Feb 18 2021 at 20:10):

Alex Crichton (Feb 18 2021 at 20:11):

this is why i'd recommend memory.write

Yehuda Katz (Feb 18 2021 at 20:11):

yeah that makes sense

Alex Crichton (Feb 18 2021 at 20:11):

b/c that's a safe API

Yehuda Katz (Feb 18 2021 at 20:11):

I was stuck on the 0.21 docs for a while

Yehuda Katz (Feb 18 2021 at 20:11):

also had no internet or power

Yehuda Katz (Feb 18 2021 at 20:11):

it was fun times :P

Alex Crichton (Feb 18 2021 at 20:12):

oh dear :(

Yehuda Katz (Feb 18 2021 at 21:39):

@Alex Crichton I'm trying to make the changes you recommended, and I was wondering why the Memory APIs use usize

Alex Crichton (Feb 18 2021 at 21:40):

I didn't review them that closely

Yehuda Katz (Feb 18 2021 at 21:40):

I guess it makes sense at a low-level, but you need to get the underlying pointers as u32 because wasm32

Yehuda Katz (Feb 18 2021 at 21:40):

so then you end up with blind casts to usize

Alex Crichton (Feb 18 2021 at 21:40):

We may want to take u64 even since there's memory64 one day too, but I think I agree that usize is wrong

Yehuda Katz (Feb 18 2021 at 21:41):

yeah I don't mind u64

Yehuda Katz (Feb 18 2021 at 21:41):

but it's not actually talking about the host's memory sizes :P

Yehuda Katz (Feb 18 2021 at 21:41):

we may want a type a la usize for the client's sizes

Yehuda Katz (Feb 18 2021 at 21:41):

csize :P

Yehuda Katz (Feb 18 2021 at 21:42):

I admit that I have given 0 thought to portability or evolution ;)

Yehuda Katz (Feb 18 2021 at 21:42):

the funny thing about the errors is that you get stern warnings like:

you can convert a `u32` to a `usize` and panic if the converted value doesn't fit rustc E0308

Alex Crichton (Feb 18 2021 at 21:44):

yeah I think rustc warnings are starting to go off the deep end...

Alex Crichton (Feb 18 2021 at 21:45):

I literally never read them

Yehuda Katz (Feb 18 2021 at 21:46):

hm so one difference between .read() and what I was doing before is that read forces you to copy out of the memory

Yehuda Katz (Feb 18 2021 at 21:46):

maybe I want that anyway?

Yehuda Katz (Feb 18 2021 at 21:46):

I was doing this before:

        &memory.data_unchecked()[(self.ptr as usize)..][..(self.len as usize)]

Yehuda Katz (Feb 18 2021 at 21:46):

which lets me have this signature:

    pub unsafe fn as_buf<'memory>(&self, memory: &'memory Memory) -> &'memory [u8] {

Yehuda Katz (Feb 18 2021 at 21:46):

obviously the unsafe is not very nice

Yehuda Katz (Feb 18 2021 at 21:47):

but it seems like as long as I have a &Memory, I ought to be able to borrow out of it safely?

Alex Crichton (Feb 18 2021 at 21:47):

yes and no, that's basically what this talks about -- https://docs.rs/wasmtime/0.23.0/wasmtime/struct.Memory.html#memory-and-safety

Yehuda Katz (Feb 18 2021 at 21:48):

I guess I don't really know what unsafe is vis a vis wasm memory

Alex Crichton (Feb 18 2021 at 21:49):

use-after-free in Rust

Alex Crichton (Feb 18 2021 at 21:49):

segfaults in Rust

Yehuda Katz (Feb 18 2021 at 21:49):

Alex Crichton (Feb 18 2021 at 21:49):

etc, etc

Alex Crichton (Feb 18 2021 at 21:49):

basically it's literal UB

Yehuda Katz (Feb 18 2021 at 21:49):

but shouldn't the RefCell be protecting us from that?

Yehuda Katz (Feb 18 2021 at 21:49):

I guess there's no way to actually lock the memory to prevent wasm code from writing to it

Alex Crichton (Feb 18 2021 at 21:49):

no b/c this has to do with UB in the Rust type system

Yehuda Katz (Feb 18 2021 at 21:49):

since it can be happily running in some other thread

Yehuda Katz (Feb 18 2021 at 21:50):

I basically want to be able to have a GIL I think :P

Alex Crichton (Feb 18 2021 at 21:50):

right so you're not looking at &[Cell<u8>]

Yehuda Katz (Feb 18 2021 at 21:50):

right

Alex Crichton (Feb 18 2021 at 21:50):

you get &mut [u8] which has a lot of Rust guarantees

Alex Crichton (Feb 18 2021 at 21:50):

but also the pointer itself is not stable

Yehuda Katz (Feb 18 2021 at 21:50):

Both Neon and Helix ended up introducing a GIL for this ~ reason

Alex Crichton (Feb 18 2021 at 21:50):

every memory.grow can invalidate it

Yehuda Katz (Feb 18 2021 at 21:50):

the truth is that copying is not so bad

Alex Crichton (Feb 18 2021 at 21:50):

indeed

Yehuda Katz (Feb 18 2021 at 21:50):

it's basically memcpy :shrug:

Alex Crichton (Feb 18 2021 at 21:50):

all copies in an out of memory are safe

Alex Crichton (Feb 18 2021 at 21:51):

(that's what interface types basically do)

Yehuda Katz (Feb 18 2021 at 21:52):

hehe MemoryAccessError

Yehuda Katz (Feb 18 2021 at 21:52):

we finally got our OOM results

Alex Crichton (Feb 18 2021 at 21:52):

yeah most of Memory is for interacting with a "possibly hostile" wasm module

Alex Crichton (Feb 18 2021 at 21:52):

but in your use case the wasm module is trusted

Yehuda Katz (Feb 18 2021 at 21:52):

yeah

Yehuda Katz (Feb 18 2021 at 21:53):

for example it seems pointless to do UTF-8 checks

Yehuda Katz (Feb 18 2021 at 21:56):

@Alex Crichton I ended up creating a WasmUnwrap trait that uses my own custom error function to panic

Yehuda Katz (Feb 18 2021 at 21:56):

is this crazy?

Yehuda Katz (Feb 18 2021 at 21:56):

basically I couldn't use the one everyone uses because I'm not JS

Alex Crichton (Feb 18 2021 at 21:57):

uh... maybe?

Alex Crichton (Feb 18 2021 at 21:57):

not entirely sure the context in which this trait exists

Alex Crichton (Feb 18 2021 at 21:57):

and fwiw I'd still do utf-8 checks and unwrap them

Yehuda Katz (Feb 18 2021 at 21:57):

we could change that crate to allow the user to customize the wasm function to call

Alex Crichton (Feb 18 2021 at 21:57):

it's always better to get panics instead of UB on busg

Yehuda Katz (Feb 18 2021 at 21:58):

yeah sure

Yehuda Katz (Feb 18 2021 at 21:58):

@Alex Crichton it's for cases where I'd have written unwrap() or expect()

Alex Crichton (Feb 18 2021 at 21:58):

in the wasm blob itself?

Yehuda Katz (Feb 18 2021 at 21:58):

yah

Alex Crichton (Feb 18 2021 at 21:58):

ah I see, yeah that works

Yehuda Katz (Feb 18 2021 at 21:58):

it assumes:

extern "C" {
    pub fn log_str(ptr: u64);
}

Yehuda Katz (Feb 18 2021 at 21:59):

which is less coupled than the JS one

Alex Crichton (Feb 18 2021 at 21:59):

this is an unfortunate thing where wasm32-wasi "just works" but wasm32-unknown-unknown doesn't

Yehuda Katz (Feb 18 2021 at 21:59):

bio break, then call

Yehuda Katz (Feb 18 2021 at 21:59):

right

Last updated: Oct 23 2024 at 20:03 UTC