pchickey
commented
1 year ago Yes, WASI Preview 1 was specified in terms of witx, which predated the component model and defined its own ABI. We defined the wasi_snapshot_preview1 module before WASI was specified as a set of proposals - the WASI spec itself was monolithic at the time.
Some WASI proposals (to my knowledge, this is only wasi-nn and wasi-crypto) have provided a witx interface in their repo so that they could be implemented as an extension to WASI Preview 1. Those proposals chose to use module namespaces of their own (e.g. wasi_ephemeral_nn, wasi_ephemeral_crypto_symmetric) for those extensions.
Proposals targeting Preview 2 need to be specified in the Component Model's wit language. When using recent additions to the wit language, proposals also get their own wit package name (e.g. wasi:io) to provide modularity similar to the module namespacing for the witx-specified proposals.
We hope that the proposals currently specified in witx will also propose wit interfaces when they are able to, but wit itself and all the component model tooling is still under constant development with occasional breaking changes at this time, so its understandable if proposals choose to wait for that progress to settle down. We we expect this churn will settle down soon, as we try to stabilize WASI proposals in order to release a Preview 2. (A plan for releasing Preview 2 will be proposed at the next WASI meeting https://github.com/WebAssembly/meetings/pull/1322.)
wasi-threads has not sought a WASI subgroup vote to advance beyond phase 1 (which only grants the proposal a repository in which to build a proposal), and it is incorrect to call it "part of preview 1".
The wasi-threads proposal was never specified in witx, but @abrown et al landed implementations their proposal in wasmtime, wasi-libc, rust and elsewhere in terms of a core wasm ABI that resembled the wit document in their spec repo. (They did so because wit tooling was in an early prototype phase and wasn't stable enough to use at the time.) Simultaneously, the component model specification and implementation progressed so that it is clear that the wasi-threads proposal, in its current form, can't be faithfully represented as a wit interface: it requires engine integration that the Component Model cannot provide.
So, the existing implementations of wasi-threads are ad-hoc in terms of a core Wasm ABI, and won't compose with other proposals specified in wit. This is fine: we expect that implementations will drift from the spec repos as part of the maturation process, because these proposals can only mature by building implementations and discovering issues. Early phases, especially phase 1, is not a promise of stability - it only indicates that specification work is in progress, and provides a place to collaborate on it.
My understanding is that, presently, @abrown, @lukewagner and others are collaborating on how to take the core ideas from wasi-threads and turn it into a core WebAssembly proposal (built on top of the WebAssembly threads proposal, which itself is at Phase 3 in the Wasm subgroup), and they also will be figuring out how their proposal will interact with the Component Model proposal. So, we don't yet know the future of wasi-threads: it may end up getting eliminated by adding spawning and destroying threads to the core Wasm spec. Or, maybe the core spec work will require some other way of getting it specified and implemented. These things take time to shake out because there are a lot of implementors collaborating from many different Wasm engines.
codefromthecrypt
wasip1 is currently in use by a lot of compilers today. It is defined completely differently than wasip2+, as it is formalized as an ABI in witx and goes into the monolithic module name "wasi_snapshot_preview1" (vs component model which is a different approach altogether and not monolithic).
Currently, the proposals list doesn't clarify the target of things, so we can't tell if something is in witx by accident of not being converted to wit, yet, or if it is intentionally supposed to be added to preview1
https://github.com/WebAssembly/WASI/blob/main/Proposals.md
Can you please add a column for which proposals are active work on preview1 vs component model? This will prevent surprise and ambiguity. This also helps compilers and runtimes plan what sort of additions are likely, as it affects design.
Case in point: @yoshuawuyts corrected my misunderstanding that wasi-threads is actually a feature ready to be a rust triple, and that it is a part of preview1. I have seen so many wasi proposals converted from witx to wit (component-model), so it wasn't obvious to me.
The ecosystem should be able to know easily what work is ahead of them, especially what's backported to wasip1 and what despite being phase 1 is really just a clerical problem and ready for compilers to implement.
See https://github.com/rust-lang/rust/pull/112922#issuecomment-1632394649 See https://github.com/WebAssembly/wasi-threads/issues/47