1. 18
  1. 1

    A blocking-like green threaded runtime could actually resolve a lot of pain points for many people currently using async instead.

    1. 2

      I think threads serve that purpose pretty well, I really need to benchmark how many theads my linux desktop actually can run.

      1. 3

        Single digit thousands IME used to work well with Apache and Varnish. Both do return threads to a pool & reuse them for multiple work items (client requests, whatever) rather than starting and stopping threads for each work item. I believe offhand that this is important for performance.

        1. 1

          Theoretically, re-using threads should reduce allocations, and (maybe?) decrease cache pressure a little. So that makes sense.

          1. 2

            Offhand I believe it’s common for closing threads to munmap() their stacks, which causes TLB shootdowns, which cause colloidal scalability problems, but I would really have to check properly.

      2. 2

        That’s exactly what this post is about: replacing async with Lunatic’s solution.

        Lunatic is an Erlang-inspired runtime for WebAssembly

        Lunatic looks a lot like Actix with the async/event-loop removed. 🤔 I have the impression that they’re targeting only WA. Does that mean that their runtime can’t run on other architectures?

        1. 1

          Looks like they’re providing a platform that uses the wasmtime wasm JIT, so part of its goal is also to act as a sandbox for untrusted code.

          We intend to eventually make Lunatic completely compatible with WASI. Ideally, you could take existing code, compile it to WebAssembly and run on top of Lunatic; creating the best developer experience possible. We’re not quite there yet.

          So the goal is to be able to run on various different WASM impl’s.