Stream: wasmtime

Topic: wasmtime-wasi re-export various crates?


view this post on Zulip fitzgen (he/him) (Mar 25 2021 at 17:57):

How do we feel about wasmtime-wasi re-exporting cap-std and wasi-cap-std-sync? As a wasmtime embedder that is configuring WASI, it is quite annoying to wrangle all these types and dependencies from different crates.

Also, ideally I would just be able to call wasi_ctx_builder.preopen_dir(path_to_dir, path_to_expose_it_as) without needing to actually do the preopen myself before passing it to the builder (which is where all these other deps start coming in).

Are we cool with these API additions? If so, I can whip up a PR.

cc @Dan Gohman @Pat Hickey

view this post on Zulip Dan Gohman (Mar 25 2021 at 17:59):

cap-std is ok with that; it's public interface is closely tied to std's interface, so it's pretty stable

view this post on Zulip Dan Gohman (Mar 25 2021 at 18:00):

I'm less confident about wasi-cap-std-sync, though I don't have specific concerns I can articulate

view this post on Zulip Dan Gohman (Mar 25 2021 at 18:02):

wasi-cap-std-sync's traits are likely to evolve, but maybe that's ok

view this post on Zulip Pat Hickey (Mar 25 2021 at 18:07):

i think its fine to re-export them using a cargo feature.

view this post on Zulip Pat Hickey (Mar 25 2021 at 18:08):

the reason cap-std-sync is a separate crate is that one day cap-std-async will exist.

view this post on Zulip Pat Hickey (Mar 25 2021 at 18:09):

so, if wasmtime-wasi wants to export wasi-cap-std-sync::WasiCtxBuilder as sync::WasiCtxBuilder, thats cool.

view this post on Zulip Pat Hickey (Mar 25 2021 at 18:09):

it can be a default feature, it is just something that some embedders (read: me, one day soon) may want to turn off

view this post on Zulip Pat Hickey (Mar 25 2021 at 18:10):

the usability right now is not good at all, and re-exporting would go a long way to improve that - make the way you are supposed to use it obvious for users who dont know the whole twisty network of crates and future plans.

view this post on Zulip fitzgen (he/him) (Mar 25 2021 at 18:54):

what about not doing the re-exporting, but having the preopen_dir builder method do the preopening, rather than taking an already preopened dir? that would eliminate the need to worry about deps completely, afaik

view this post on Zulip Alex Crichton (Mar 25 2021 at 18:57):

Is there a downside to reexporting? Regardless of their stability they're a public dependency of wasmtime-wasi and I think fitzgen's got a good point that wrangling a bunch of crates with disparate versions isn't the most enjoyable thing to do

view this post on Zulip Alex Crichton (Mar 25 2021 at 18:57):

although I think ideally we'd refactor the wasmtime-wasi crate to have an api which has fewer transitive crates as public dependencies

view this post on Zulip Pat Hickey (Mar 25 2021 at 20:44):

Yea we can fold the preopening into the builder so all Wasmtime-wasi has to re-export is the builder.

view this post on Zulip Pat Hickey (Mar 25 2021 at 21:13):

@fitzgen (he/him) should i make those changes to wasmtime-wasi or will you?

view this post on Zulip fitzgen (he/him) (Mar 25 2021 at 21:22):

if you have cycles now, go for it, I'm a bit busy making benchmarks/demos for my wasm summit talk at the moment

view this post on Zulip Pat Hickey (Mar 25 2021 at 21:29):

ok. ill take care of it in a little bit. im on openssl 1.1.1k duty right now, apparently

view this post on Zulip fitzgen (he/him) (Mar 25 2021 at 21:46):

thanks!

view this post on Zulip fitzgen (he/him) (Mar 25 2021 at 21:47):

quick question: wasmtime_wasi::Wasi::new still takes a store as a parameter, but I want to add it to a Config, not a Linker. Can I just use a dummy store?

view this post on Zulip fitzgen (he/him) (Mar 25 2021 at 21:49):

hm wait but I can't make a Store yet because I'm still building the Config for my Engine...

view this post on Zulip Peter Huene (Mar 25 2021 at 21:58):

Oh sorry, I missed this convo. Yeah, with Wasi::add_to_config you call Wasi::set_context to set the WasiCtx in the store

view this post on Zulip Peter Huene (Mar 25 2021 at 21:58):

i agree it's pretty confusing having two ways to do this

view this post on Zulip Peter Huene (Mar 25 2021 at 21:59):

when using the functions defined in a config, we never actually create an instance of Wasi

view this post on Zulip Peter Huene (Mar 25 2021 at 21:59):

which itself is just a holder of Func

view this post on Zulip fitzgen (he/him) (Mar 25 2021 at 22:27):

okay, got everything working now, thanks :)

view this post on Zulip Pat Hickey (Mar 25 2021 at 22:36):

make sure you do store.add(Rc::new(RefCell::new(wasi_ctx))

view this post on Zulip Pat Hickey (Mar 25 2021 at 22:36):

or else it will fail at runtime

view this post on Zulip Peter Huene (Mar 25 2021 at 22:37):

Wasi::set_context encapsulates that

view this post on Zulip Pat Hickey (Mar 25 2021 at 22:38):

oh cool

view this post on Zulip Pat Hickey (Mar 25 2021 at 22:38):

idk why i didnt see that, you said it right there

view this post on Zulip Pat Hickey (Mar 25 2021 at 22:38):

i blame openssl

view this post on Zulip Peter Huene (Mar 25 2021 at 22:39):

:shakes fist at openssl:

view this post on Zulip Pat Hickey (Mar 26 2021 at 00:07):

https://github.com/bytecodealliance/wasmtime/pull/2776

Until more impls come along, every user of wasmtime-wasi is going to use wasi-cap-std-sync as their WasiCtxBuilder. Rather than make our users track a dependency on an additional crate, re-export i...

Last updated: Oct 23 2024 at 20:03 UTC