## Cosmonic hackathon Feb 16

wasmex -> update to latest wasmtime
It's trailing behind, not all of the configuration values are surfaced, with rust, many things need to be enabled at compilation time, e.g. crates with features.

We need to modify all of the API's to support new features.

Ran into test failures
https://github.com/tessi/wasmex/pull/402

Use wasmtime hash with wasi-threads and wasi-sockets:
c3c16eb207eccd895f5fbbc4b771bd74ea36d071

Experimenting with new features in wasmtime is exceptionally painful.
Working with NIFs is also extremely painful.

WASMEX_BUILD=true mix test

# wasmtime = "4.0.0"
wasmtime = { git = "https://github.com/bytecodealliance/wasmtime.git", rev = "dev" }
wasmtime-wasi = { git = "https://github.com/bytecodealliance/wasmtime.git", rev = "dev" }
wasi-common = { git = "https://github.com/bytecodealliance/wasmtime.git", rev = "dev" }
wiggle = { git = "https://github.com/bytecodealliance/wasmtime.git", rev = "dev" }
wat = "1.0.59"

Three different build failures in the CI.
- No responders flakey test for linux
- Windows doesn't respect the build flags
- macos needed an older version of wasmtime, seems to use prebuilt?

> The `caller` MUST be used instead of a `store` in Wasmex API functions.
Wasmex might deadlock if the `store` is used instead of the `caller`
(because running the Wasm instance holds a Mutex lock on the `store` so
we cannot use that store again during the execution of an imported function).
The caller, however, MUST NOT be used outside of the imported functions scope.

Can we use threads?

https://github.com/WebAssembly/wasi-sdk/releases/tag/wasi-sdk-20+threads

Future roadmap for WASI

https://github.com/WebAssembly/WASI/issues/515