Stream: git-wasmtime

Topic: wasmtime / PR #10030 WIP: Add wasmtime_linker_define_wasi...


view this post on Zulip Wasmtime GitHub notifications bot (Jan 16 2025 at 04:23):

thewtex opened PR #10030 from thewtex:c-api-wasi-threads to bytecodealliance:main:

To define wasi_threads on the linker to support rrunning wasm threads.

view this post on Zulip Wasmtime GitHub notifications bot (Jan 16 2025 at 04:25):

thewtex edited PR #10030:

To define wasi_threads on the linker to support running wasi-threads modules.

view this post on Zulip Wasmtime GitHub notifications bot (Jan 16 2025 at 16:46):

pchickey commented on PR #10030:

The wasi-threads implementation is not compatible with the wasmtime-wasi implementation. They require the wasi-common implementation, which is legacy and only remains in the tree because it is compatible with wasi-threads. We offer it in the CLI right now but adding support for threads to the C API is a big undertaking and requires more than just this linker addition.

I am not super enthusiastic about adding support for wasi-threads because it is a dead end proposal: it is a prototype that won’t ever progress past its current phase, and all effort on that work has shifted to fixing the deficiencies in the core wasm thread model that it uncovered, in the https://github.com/WebAssembly/shared-everything-threads proposal. Any support for threading with wasmtime-wasi needs shared-everything-threads to land in wasmtime first.

I don’t think that making wasi-threads available in more contexts serves our ecosystem well, because the binaries will not be compatible with the shared-everything approach that everyone believes is the future path.

view this post on Zulip Wasmtime GitHub notifications bot (Jan 16 2025 at 21:10):

alexcrichton commented on PR #10030:

For some added context the discussion here started over in https://github.com/bytecodealliance/wasmtime-py/issues/253 which led to this. I didn't realize (or more accurately, forgot) what it would take to support wasi-threads in its current state in the C API. I for example forgot that it needed wasi-common and that reintegrating that into wasmtime-c-api would be relatively significant.

Given that and what @pchickey mentioned above I'm shifting stances on this myself. I agree we probably shouldn't go down this road which would mean that https://github.com/bytecodealliance/wasmtime-py/issues/253 would be closed as "this won't be supported". I apologize for the runaround here @thewtex I can try to do more homework on my end next time!

view this post on Zulip Wasmtime GitHub notifications bot (Jan 16 2025 at 22:57):

thewtex closed without merge PR #10030.

view this post on Zulip Wasmtime GitHub notifications bot (Jan 16 2025 at 22:57):

thewtex commented on PR #10030:

I understand the reasoning, but I am disappointed that there is currently no way to have threading outside the CLI. :cry:


Last updated: Jan 24 2025 at 00:11 UTC