3 ms·

From the FAQ: Each process has its own stack, heap, and even syscalls. If one process fails, it will not affect the rest of the system. This allows you to crea

From the FAQ: Each process has its own stack, heap, and even syscalls. If one process fails, it will not affect the rest of the system. This allows you to create very powerful and fault-tolerant abstraction. This is also true for some other runtimes, but Lunatic goes one step further and makes it possible to use C bindings directly in your app without any fear. If the C code contains any security vulnerabilities or crashes, those issues will only affect the process currently executing the code. The only requirement is that the C code can be compiled to WebAssembly. So as I understand it, an Erlang process can "crash" from an Erlang perspective and it's fine (and even encouraged!), but if it crashes from a system perspective (segfault or some such), it takes down all neighbouring processes as well - usually an issue when using foreign libraries. With this set up, one of your erlang processes can segfault and it's fine? I have to admit I'm not across using WASM as a general purpose backend.

peoplefromibiza 4y ago
> but if it crashes from a system perspective (segfault or some such), it takes down all neighbouring processes as well there are three different types of crashes in Erlang. First there are processes `spawn`ed with the spawn primitive. If such a process crashes, there's no risk for any other process in the system, not even exceptions can bubble up (or be intercepted for that matter). The second type is a linked process, a process whose faith has been linked to their children. In that situation if a parent process dies, intuitively all the children processes die with it too. If a child process dies, it brings down the parent too, and if the parent process is a child itself, recursively until the top Application process. It sounds risky until you realize that this mechanism allows parent processes to intercept child processes dying and act accordingly (restart one, restart all, ignore it, etc.) That's how supervision works in Erlang. Finally, if a process crashes when running as NIF (Native Implemented Function) or, to put it simply, a native library written in C (or that can export the same C calling convention) injected into the VM, it can bring down the entire VM.

peoplefromibiza 4y ago

> but if it crashes from a system perspective (segfault or some such), it takes down all neighbouring processes as well there are three different types of crashes in Erlang. First there are processes `spawn`ed with the spawn primitive. If such a process crashes, there's no risk for any other process in the system, not even exceptions can bubble up (or be intercepted for that matter). The second type is a linked process, a process whose faith has been linked to their children. In that situation if a parent process dies, intuitively all the children processes die with it too. If a child process dies, it brings down the parent too, and if the parent process is a child itself, recursively until the top Application process. It sounds risky until you realize that this mechanism allows parent processes to intercept child processes dying and act accordingly (restart one, restart all, ignore it, etc.) That's how supervision works in Erlang. Finally, if a process crashes when running as NIF (Native Implemented Function) or, to put it simply, a native library written in C (or that can export the same C calling convention) injected into the VM, it can bring down the entire VM.