Wasmroutines

[mfateev]

How hard would be to add ability to execute multithreaded code (from WebAssembly app point of view) by a single system thread? Something like https://github.com/WebAssembly/design/issues/1321?

[MaxGraey]

Coroutines, fibers, green threads is usually many-to-one concurrency (no real parallelism, which one to one or some hybrid like in goroutines) based on continuation / FSM like async/await, generators. It require CFG transformations / codegeneration. Also coroutines, fibers and etc is high-level abstractions which not present in WebAssembly MVP. Basically WebAssembly presents only atomics and futex and hasn't pthreads, vfork, mutex and etc. You could polyfill atomics for example but futexes (atomic.wait / atomic.notify) should require complex CFG transformations to some sort of FSM for simulate on single thread without blocking execution. So I guess all this transformations should provide build tools, not interpreter

[mfateev]

My idea is that coroutines and fibers, etc, should not be part of the wasm high level abstrations. The wasm abstraction is threads and futexes. It is the container implementation choice to not to implement real multithreading, but use stackful coroutines to run them. There are dozens of libraries implementing stackful coroutines, so I don't think it requires CFG transformations and FSMs.

[MaxGraey]

WebAssembly hasn't shadow stack, so you can't implement stackful coroutines inside wasm but You could implement stackless approach on interpreter's side of course but I'm not sure it will be easy anyway. Also stackful coroutines usually slower than stackless ones (with FSM codegen)

[soundandform]

I've thought about this a little bit previously. Coroutines/fibers could be implemented entirely within the compiled Wasm domain as-is (which is what I think you're imagining @MaxGraey?). But it would probably be a complicated pain -- but not one we'd have to deal with personally. Regardless, my gut says: it would be much easier, more straightforward and also facilitate tracing/debugging if fibers existed outside of Wasm code, in the runtime (whether that's interpreted or not.) I think this is what you're (@mfateev) getting at. I think this could be fairly easy. Create a set of exported APIs: CoroutineStart ("FunctionName"), CoroutineYield (), etc. The runtime would be responsible for linking these to the outside world -- creating actual fiber and performing the context switches (using boost::context or similar). Maybe these calls could eventually become dedicated Wasm opcodes.

[mfateev]

@soundandform My proposal is to use existing atomic.* opcodes as from the Wasm domain there is no really difference if threads are system or green ones.

[unicomp21]

Has anyone compiled boost fibers w/ emscripten yet? To show a working demo?

[jeffRTC]

@unicomp21 Were you able to use Boost Fibers with Emscripten?

[unicomp21]

No, currently hoping for a coawait option.

On Wed, Dec 2, 2020 at 1:58 PM jeffRTC notifications@github.com wrote:

@unicomp21 https://github.com/unicomp21 Were you able to use Boost Fibers with Emscripten?

— You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub https://github.com/wasm3/wasm3/issues/32#issuecomment-737460785, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAEFL7PP5QJZSOLMW57LRB3SS2L43ANCNFSM4KBYNF5Q .