Stream: git-wasmtime

Topic: wasmtime / Issue #777 The `wasmtime::Store` type should b...


view this post on Zulip Wasmtime GitHub notifications bot (Apr 29 2020 at 17:47):

alexcrichton closed Issue #777:

As proposed in #708 the Store type in the wasmtime API should be thread-safe, meaning it should implement both Send and Sync. Currently, however, it has a few items that are not thread safe and/or need audits:

view this post on Zulip Wasmtime GitHub notifications bot (May 08 2020 at 15:10):

DemiMarie-parity commented on Issue #777:

@alexcrichton why is this impossible?

view this post on Zulip Wasmtime GitHub notifications bot (May 08 2020 at 16:03):

alexcrichton commented on Issue #777:

@DemiMarie-parity the way things are set up right now you instantiate Instance structures into a Store. The Store keeps a handle on each Instance, so effectively a Store stores each Instance. This is done to keep each Instance alive since we don't have a GC right now to otherwise understand when there are no references to an Instance.

Instances themselves are fundamentally not Sync because operations like global get/set aren't atomic. They're ideally Send, however, but with the Rc that we're using for memory management that forces them to not be Send.

The current state of affairs is that basically Store stores enough instance-local information that it can't be shared across threads because instances can't be shared across threads. There may still be internal refactorings or possible designs to fix this, but overall our threading story isn't great right now unfortunately.

view this post on Zulip Wasmtime GitHub notifications bot (May 08 2020 at 16:24):

DemiMarie-parity commented on Issue #777:

@alexcrichton what if we used Arc instead? I imagine that reference count operations are not in hot paths.

view this post on Zulip Wasmtime GitHub notifications bot (May 08 2020 at 18:01):

alexcrichton commented on Issue #777:

Unfortunatey it's not quite as easy as that. In Rust there's no way to statically have a reference counted type that's Send but not Sync, which is morally what we'd want here. The only static solution for that is to entirely remove the reference counting, but that doesn't jive well with the memory management that we have in wasmtime today.

Failing that we'd have to invent our own solution in wasmtime which is much more invasive than just using an Arc instead of an Rc, and I'm not really sure if that's even possible much less workable.

view this post on Zulip Wasmtime GitHub notifications bot (May 08 2020 at 19:12):

DemiMarie-parity commented on Issue #777:

What would need to change to allow JIT-compiled code to be used by multiple threads simultaneously?

view this post on Zulip Wasmtime GitHub notifications bot (May 08 2020 at 19:15):

DemiMarie-parity commented on Issue #777:

The first idea that comes to mind is to separate the JIT-compiled code (which is immutable) from the data (which is mutable). So to execute some code, one would first need to compile it, which would return an immutable CompiledBlob object. One would then need to create an Instance from the CompiledBlob. Since a CompiledBlob is immutable, making it Send + Sync is trivial.

view this post on Zulip Wasmtime GitHub notifications bot (May 08 2020 at 19:20):

DemiMarie-parity deleted a comment on Issue #777:

The first idea that comes to mind is to separate the JIT-compiled code (which is immutable) from the data (which is mutable). So to execute some code, one would first need to compile it, which would return an immutable CompiledBlob object. One would then need to create an Instance from the CompiledBlob. Since a CompiledBlob is immutable, making it Send + Sync is trivial.

view this post on Zulip Wasmtime GitHub notifications bot (May 11 2020 at 17:43):

alexcrichton commented on Issue #777:

Ah yes so sharing Store is its own issue but sharing compiled code is definitely something that we want to enable. Making Module both Send and Sync should be easier than making Store either Send or Sync, and that's largely just a matter of internal refactorings.

view this post on Zulip Wasmtime GitHub notifications bot (May 11 2020 at 23:09):

yurydelendik commented on Issue #777:

FWIW wasm-c-api planed to shared a module between two stores via wasm_module_share/wasm_module_obtain , see https://github.com/WebAssembly/wasm-c-api/blob/master/example/threads.c#L34


Last updated: Dec 23 2024 at 12:05 UTC