Stream: git-wasmtime

Topic: wasmtime / issue #5302 Wiggle: make wasmtime an optional ...

Wasmtime GitHub notifications bot (Nov 19 2022 at 15:07):

Berrysoft opened issue #5302:

Feature

Wiggle will forcely depend on wasmtime in future releases, according to #5137 . However, recently wasmi begins support for WASI with wiggle (https://github.com/paritytech/wasmi/pull/557). We need to avoid importing wasmtime when using it. With the current latest version 2.0.x, it is easy to control with features, but this will not work in future releases.

Therefore I suggest making wasmtime an optional dependency of wiggle again.

Benefit

Wasmtime is a de facto standard of WASM. It provides many standard implementations and benefits many other projects in the community. Cranelift is a good example, it is not only a JIT of wasmtime, but also a codegen of many frontends. If wiggle provide an option to remove wasmtime dependency, it (and wasi-common) could be another standard implementation of WASI.

Implementation

I'm aware of the huge work to make a dependency optional, but I think it worth. If there are no prettier attempts, reverting the commit might be a choice.

Wasmtime GitHub notifications bot (Nov 19 2022 at 15:12):

bjorn3 commented on issue #5302:

You might want to read the thread at https://bytecodealliance.zulipchat.com/#narrow/stream/219900-wasi/topic/wasi-common.3A.20General.20WASI.20implementation.3F

Wasmtime GitHub notifications bot (Nov 21 2022 at 17:54):

alexcrichton commented on issue #5302:

Personally I can see the value in having an implementation of a host API decoupled from the wasm engine it's running on, but such an implementation requires a fair bit of macro-trickery to keep it maintainable. The wiggle of old, as you've found, did this as it was multiplexing the Lucet and Wasmtime runtimes. Nowadays, however, the design of wasi-common is evolving, especially with an upcoming implementation of the preview2 snapshot of WASI. With all the shuffling going on we need to focus on the needs of Wasmtime and the component model right now. Once the dust settles I think it would be reasonable to look at this issue again and see where things are at and whether it can be reasonably supported. For now though I'm going to close this as this was something intentionally removed (with more information on Zulip as well in that linked thread)

Wasmtime GitHub notifications bot (Nov 21 2022 at 17:54):

alexcrichton closed issue #5302:

Feature

Wiggle will forcely depend on wasmtime in future releases, according to #5137 . However, recently wasmi begins support for WASI with wiggle (https://github.com/paritytech/wasmi/pull/557). We need to avoid importing wasmtime when using it. With the current latest version 2.0.x, it is easy to control with features, but this will not work in future releases.

Therefore I suggest making wasmtime an optional dependency of wiggle again.

Benefit

Wasmtime is a de facto standard of WASM. It provides many standard implementations and benefits many other projects in the community. Cranelift is a good example, it is not only a JIT of wasmtime, but also a codegen of many frontends. If wiggle provide an option to remove wasmtime dependency, it (and wasi-common) could be another standard implementation of WASI.

Implementation

I'm aware of the huge work to make a dependency optional, but I think it worth. If there are no prettier attempts, reverting the commit might be a choice.

Last updated: Oct 23 2024 at 20:03 UTC