This certainly seems like a reasonable setup. My first reaction would be why not just build with `USE_PTHREADS=1`? This is the canonical way to tell emscripten to use shared memory. If you don't actually start any threads I'm not sure what costs it has. What "extra complexity of the WebAssembly threading model" are you referring to here?
If there are indeed significant costs to running single threaded programs built with `USE_PTHREADS=1` then we can look into adding a separate option for using shared memory, but I think it will be tricky to persuade the linker wasm-ld to accept both shared memory, and object files build for non-shared memory. As a hacky workaround, you could always provide your own memory by setting `Module['wasmMemory']` before loading the generated JS and then set the memory flag to shared using `wasm-dis + edit + wasm-as`. Obviously not ideal but maybe good for experimenting. cheers, sam On Tue, Oct 27, 2020 at 12:27 AM Soeren Balko <[email protected]> wrote: > I've been running into an issue with Emscripten, where I cannot use a > shared WebAssembly.Memory (ie., backed by a SharedArrayBuffer) in a > single-threaded build. The rationale for this is to be able to use the > Emscripten heap as a shared state with other workers / the UI thread. > Specifically, it would allow us to directly copy data to the heap in other > threads, avoiding to copy data. > > Our scenario looks like this: > (1) We run a (single-threaded) WebAssembly module in a worker in a > long-running synchronous call; > (2) From within the synchronous call stack, the wasm module calls into JS > to dispatch some work to the UI thread; > (3) We currently COPY the data from the WebAssembly.Memory heap to a > separate SharedArrayBuffer, which we then postMessage to the main thread. > (4) The worker then uses a wait/notify pattern to block the Emscripten > call stack until the UI thread has passed back a result on the > SharedArrayBuffer > (5) The UI thread can meanwhile perform some asynchronous work (eg., > IndexedDB, etc.) and store the response in the SharedArrayBuffer, then > notify the waiting worker. > (6) The waiting worker then has to COPY the result from the > SharedArrayBuffer back onto the Emscripten heap and return. > > In effect, we're performing two (expensive) copies. If the Emscripten heap > was using a SharedArrayBuffer, we could trivially share that with the UI > thread and merely pass offsets on the heap around. > > So in summary, are there any plans to supporting an SAB-backed > WebAssembly.Memory for scenarios like these? I understand that a > multi-threaded build could accomplish this. However, the extra complexity > of the WebAssembly threading model (especially when running the WebAssembly > module inside a worker) is not really acceptable in this case. > > Soeren > > -- > You received this message because you are subscribed to the Google Groups > "emscripten-discuss" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/emscripten-discuss/283659cd-4e07-4913-a185-e4e9495f8d12n%40googlegroups.com > <https://groups.google.com/d/msgid/emscripten-discuss/283659cd-4e07-4913-a185-e4e9495f8d12n%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "emscripten-discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/CAL_va2_82PfYNs7%3DFHXfobPDQKt23Rg6nx3AhkhrFfbiJzTVoQ%40mail.gmail.com.
