Stream: git-wasmtime

Topic: wasmtime / issue #888 Tracking issue for supporting multi...

Wasmtime GitHub notifications bot (Sep 23 2021 at 09:37):

sparker-arm commented on issue #888:

Hi @alexcrichton, is this still the current TODO list for threading support? This there a more detailed roadmap to look at?

Wasmtime GitHub notifications bot (Sep 23 2021 at 10:19):

bjorn3 commented on issue #888:

Cranelift has support for atomics, so that checkbox should be checked.

Wasmtime GitHub notifications bot (Sep 23 2021 at 15:35):

alexcrichton commented on issue #888:

AFAIK it's basically still relevant, yeah. I don't believe that much work has been done to implement this in Wasmtime. I believe that most atomic operations are supported in Cranelift now as-mentioned but that's just the tip of the iceberg. I'm not sure how thoroughly tested they are or whether there's some missing instructions needing an implementation. I also don't know if normal loads/stores with memory need to be updated and/or change codegen in a shared-memory world. Overall I don't think we're in the position where we can simply say Cranelift is "done" and the work is elsewhere, but I could be wrong!

There's still quite a lot to do with Wasmtime itself. Designing shared memories and how that will work has not yet been done.

Wasmtime GitHub notifications bot (Oct 01 2021 at 19:21):

akirilov-arm edited issue #888:

I've noticed that there's a few issues related to threads lying around, so I figure it's a good idea to go ahead and open a dedicated tracking issue for various work items. The work here that needs to happen I believe is:

• [x] Cranelift needs atomics support - bytecodealliance/cranelift#582
• [ ] Ensure wasmtime internal data structures are threadsafe
  • wasmtime_runtime::LinearMemory
  • wasmtime::{Store, Module, Memory} (see https://github.com/bytecodealliance/wasmtime/issues/777)
  • ...
• [ ] Design a WASI (or other) API to spawn a thread
• [ ] Port an existing library to this infrastructure and prove it out.

Wasmtime GitHub notifications bot (Oct 01 2021 at 19:22):

akirilov-arm edited issue #888:

I've noticed that there's a few issues related to threads lying around, so I figure it's a good idea to go ahead and open a dedicated tracking issue for various work items. The work here that needs to happen I believe is:

• [ ] Cranelift needs atomics support - bytecodealliance/cranelift#582
• [ ] Ensure wasmtime internal data structures are threadsafe
  • wasmtime_runtime::LinearMemory
  • wasmtime::{Store, Module, Memory} (see https://github.com/bytecodealliance/wasmtime/issues/777)
  • ...
• [ ] Design a WASI (or other) API to spawn a thread
• [ ] Port an existing library to this infrastructure and prove it out.

Wasmtime GitHub notifications bot (Jun 08 2022 at 17:16):

alexcrichton labeled issue #888:

I've noticed that there's a few issues related to threads lying around, so I figure it's a good idea to go ahead and open a dedicated tracking issue for various work items. The work here that needs to happen I believe is:

• [ ] Cranelift needs atomics support - bytecodealliance/cranelift#582
• [ ] Ensure wasmtime internal data structures are threadsafe
  • wasmtime_runtime::LinearMemory
  • wasmtime::{Store, Module, Memory} (see https://github.com/bytecodealliance/wasmtime/issues/777)
  • ...
• [ ] Design a WASI (or other) API to spawn a thread
• [ ] Port an existing library to this infrastructure and prove it out.

Wasmtime GitHub notifications bot (Mar 09 2023 at 12:49):

muayyad-alsadi commented on issue #888:

I have a question when we say threading support do we mean the ability to

• to start a thread from a wasm function
• to be safely called from two different threads (that are started outside wasm ex. by the WASI env, eg. python)

I'm more interested in the second

Wasmtime GitHub notifications bot (Mar 09 2023 at 15:34):

bjorn3 commented on issue #888:

We already support running entirely independent wasm instances on multiple threads. As for wasm instances sharing resources, that is a prerequisite of being able to spawn threads from within wasm.

Wasmtime GitHub notifications bot (Mar 09 2023 at 17:16):

abrown commented on issue #888:

@muayyad-alsadi, for the "spawning a thread" question, you might be interested in wasi-threads, which you could read about in this blog post. For the second question, I think @bjorn3 is right; I would just add that care has been taken to ensure that the API is thread-safe, mainly by using Rust's thread-safety restrictions. E.g., if you try to do something unsafe using Wasmtime's API, the Rust compiler should complain.

@alexcrichton, I think we can close this issue?

Wasmtime GitHub notifications bot (Mar 09 2023 at 18:41):

alexcrichton commented on issue #888:

Agreed!

Wasmtime GitHub notifications bot (Mar 09 2023 at 18:41):

alexcrichton closed issue #888:

I've noticed that there's a few issues related to threads lying around, so I figure it's a good idea to go ahead and open a dedicated tracking issue for various work items. The work here that needs to happen I believe is:

• [ ] Cranelift needs atomics support - bytecodealliance/cranelift#582
• [ ] Ensure wasmtime internal data structures are threadsafe
  • wasmtime_runtime::LinearMemory
  • wasmtime::{Store, Module, Memory} (see https://github.com/bytecodealliance/wasmtime/issues/777)
  • ...
• [ ] Design a WASI (or other) API to spawn a thread
• [ ] Port an existing library to this infrastructure and prove it out.

Last updated: Dec 23 2024 at 12:05 UTC