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.
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.
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?
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.
A blocking-like green threaded runtime could actually resolve a lot of pain points for many people currently using async instead.
I think threads serve that purpose pretty well, I really need to benchmark how many theads my linux desktop actually can run.
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.
Theoretically, re-using threads should reduce allocations, and (maybe?) decrease cache pressure a little. So that makes sense.
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.
That’s exactly what this post is about: replacing async with Lunatic’s solution.
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?
Looks like they’re providing a platform that uses the
wasmtimewasm JIT, so part of its goal is also to act as a sandbox for untrusted code.So the goal is to be able to run on various different WASM impl’s.