Closed leon-thomm closed 3 months ago
I admit I have no experience with wasm
targets, but my guess is that supporting wasm
with the current multi-threaded executor architecture would be difficult. As you noted, even in single-threaded mode, 1 worker thread is always spawned from the main executor thread and changing this behavior would be a major change.
There is, however, a plan to provide a dedicated single-threaded simulator with !Sync
channels and tasks. The primary motivation for this is to eliminate atomic synchronization overhead for light workloads that do not benefit from parallel execution, but it would certainly make sense to ensure it supports wasm32-wasi
out of the box. I can't give any horizon for this though, it is only a medium-level priority at the moment.
I am very curious about your use-case: are you at the liberty to share why you wish to run Asynchronix on a wasm
target?
In any case, I will leave this issue open to ensure it is not forgotten when work on a single-threaded simulator begins.
There is, however, a plan to provide a dedicated single-threaded simulator with
!Sync
channels and tasks. [...] it would certainly make sense to ensure it supportswasm32-wasi
out of the box.
That sounds great.
I am very curious about your use-case: are you at the liberty to share why you wish to run Asynchronix on a
wasm
target?
For portability. I recently wrote a tiny cache coherence simulator with several parameters (block size, replacement policy, etc.), and it turned out useful that I could simply compile it to wasm32-wasi
and send the .wasm
file to my peers, who can run small benchmarks with their own configurations in an arbitrary environment (with quite reasonable performance, actually). But I understand that this might not be top of the agenda.
Just a small update: this will be resolved in v0.3 (already works in our private branch).
Done, courtesy of #24! :tada:
In fact it is now even possible to use the simulator API from the JS side via protobuf messages, but this is for now a somewhat experimental feature. There is sadly no JS library to abstract the protobuf layer at the moment, so one must perform (de)serialization in JS based on the simulation.proto
schema, for instance with protobuf.js
.
This won't make its way to crates.io before v0.3 is officially published though.
Are there any plans to provide
wasm32-wasi
target support, presumably with single threaded simulation fallback? This would increase portability (for a developer) and security (for a client) for non-performance critical testing purposes.Currently, the espresso machine example compiles successfully with
but running the generated
espresso_machine.wasm
on a WASM VM will fail where the executor tries to spawn threads unchecked. As far as I know, all use ofstd
APIs not supported by WASI (such as threading) will need to be made target-dependent with macros.I am not sure how much asynchronix depends on multi-threading and unsafe code, and hence how hard it would be to introduce fallbacks for WASI.