Stream: git-wasmtime

Topic: wasmtime / issue #7734 Support custom scheduling of WASM ...

Wasmtime GitHub notifications bot (Dec 30 2023 at 13:40):

veluca93 opened issue #7734:

Feature

As far as I could tell, the current implementation of shared memory and in particular the atomic_wait instructions will eventually block the calling thread (https://github.com/bytecodealliance/wasmtime/blob/b583c54fda13b53dea362861125dd1e2ced1381d/crates/runtime/src/parking_spot.rs#L169). This makes it impossible (I think) to implement custom scheduling of WASM threads, leaving control to the OS.

Benefit

Being able to fully control WASM thread scheduling would allow some interesting usecases for embedders:

• deterministic concurrent-but-not-parallel executions (by implementing a scheduler that cycles between non-waiting threads after a certain amount of fuel is consumed in a controlled way)
• debugging utilities for multi-threaded code that explore different execution orders to catch race conditions
• (maybe?) execution of multi-threaded WASM code without OS threads assuming that the wasmtime-fiber implementation is adapted

Implementation

My first idea would be to (optionally) modify the SharedMemory implementation of atomic_wait/atomic_notify to instead behave similarly to the implementation of fuel_async_yield_interval, yield control back to the caller and have them figure out how to do scheduling and when to resume the WASM thread.

Alternatives

I believe it should be possible to implement this behaviour also by replacing the calls to the atomic instructions with call to user-specified async Funcs, which might possibly have better ergonomics (in principle, such a modification could be done without explicit support from wasmtime itself)

Wasmtime GitHub notifications bot (Jan 02 2024 at 18:58):

alexcrichton commented on issue #7734:

I agree it would be good to have embedder-configurable hooks here! Yielding control back to the caller is not easy in the synchronous-call-to-wasm case because the API doesn't really afford for that, but for the async case I definitely agree that yielding back is the way to go here. That'd take some plumbing to get that all hooked up, for example when suspending a future we'd need to record the Waker to get woken when a memory.atomic.notify happens. Nothing that can't be done, however!

Last updated: Nov 22 2024 at 16:03 UTC