Update Wasmtime's available features and how they are accessed

[abrown]

Wasmtime now has support for the threads proposal; this change adds that. It also uses the correct --wasm-features flag for enabling optional features.

[abrown]

cc: @RReverser, @sbc100?

[andylizi]

SyntaxError: Expected double-quoted property name in JSON at position 5855

The trailing comma is breaking the site.

[sbc100]

Oops, lets revert.

[abrown]

Ok, I opened #315 that solely fixes the flag syntax. Let's figure out what to do about the thread proposal line below...

[RReverser]

Also we intentionally kept N/A (null rather than false) for WASI engines since, even if technically they support stoics, there is no way to spawn threads in WASI yet, so that functionality is not accessible by direct users.

I don't think anything changed in WASI in that regard yet?

[andylizi]

My understanding of N/A is more along the lines of, "the feature in question doesn't make sense for this platform." For example, JS BigInt integration is N/A for wasmtime, because wasmtime doesn't have anything to do with JS interop.

But wasmtime is certainly going to support threads eventually, and it makes sense for it to do so considering its use cases for running Wasm on backend servers. So IMHO even though the API design isn't there yet, from a user's standpoint, I feel "currently not supported" would be a more fitting description.

[abrown]

@RReverser, @andylizi: I think this cell in the roadmap table indicates support for the Wasm threads proposal, which consists of shared memory, atomic operations, and wait/notify. As mentioned, that proposal contains no mechanism for spawning threads. But "implementing the proposal" is completely possible without the ability to spawn threads: if the instructions are supported and the tests pass, I believe that is enough to consider a Wasm proposal supported. Wasmtime does this behind the --wasm-features=threads flag so it feels to me like this cell should in fact reflect that.

But there's more: I (and others) have been working on a WASI proposal to add a mechanism for spawning threads in WASI--wasi-threads. Wasmtime is just now gaining support for that (I'm working through several details) as is WAMR. There are many questions here and everything is very experimental, but I'm just pointing out that there is an in-progress way to spawn threads. IMHO I don't think this needs to play a large part in how the cell is filled in (that seems a "does the engine implement the Wasm proposal?" question) but it may change the equation for you all. Thoughts?