Hacker News Reader

Comment by nomaxx117 | Hacker News Reader

WASM has far more potential for serverless usage than it does in the browser.

I think Cloudflare's Workers are a good example of where things might be going with the tech, but there is room for a lot more. I would love to see something like coroutines adopted for WASM that allow for asynchronous WASM computation.

View on HN

Coroutines are usually a language level construct (syntax sugar for a switch-case statemachine). Machine code doesn't have "coroutine support" either yet all languages with coroutine support run just fine on regular CPUs.

> Machine code doesn't have "coroutine support" either yet all languages with coroutine support run just fine on regular CPUs.

Yes and no.

Some ISAs do have real "co-instructions" that would be executed concurrently to the "main" program, for example Lisp Machines use this approach for executing bounds-checking concurrently, as well as other kinds of validation/assertions (and even had a limited form of hardware time-travel to jump-back to before a co-processor exception occurred).

This approach died out due to the complexity of implementation.

Coroutines are present at the language and runtime level. Most languages with coroutines have runtimes baked in that handle them behind the scenes (think of JS), but some (like Rust) require you to provide your own. Async executors are quite large in terms of code size, so I think it would be useful for WASM to expose a coroutine interface for compilers to target. I think that not having to ship your asynchronous runtime would be very beneficial.

Usually a syntax sugar? Not true, unless you give up ability to call function and switch/resume coroutine seamlessly inside it. You need the ability to manipulate call stack. Regular CPUs have no problem with that but wasm expressly disallows it. So any language with coroutines needs to avoid using wasm stack.

I guess you mean fibers (which require call stack switching). That's one way to implement coroutines, but most languages with async/await implement coroutines differently by transforming async functions into a simple switch-case state machine (where each "yield block" is one case-branch) plus associated local state which doesn't live on the regular call stack. This code transformation is also the reason for "function coloring", which isn't needed for a fiber-based coroutine system.

Reply on news.ycombinator.com