3 ms·
I'd agree if it crashed the calling process, but crashing the entire VM is way too noisy of a way to go out.
by sb8244 7y ago
I'd agree if it crashed the calling process, but crashing the entire VM is way too noisy of a way to go out.
- lostjohnny 7y agoDo you know other VMs that resist a crash in external, native, unchecked code? A NIF is basically VM code that undergo some minor limitation and runs at full speed. BEAM is not a sandbox and will (probably) never be. The most important lesson Erlang teaches is that there could be no recovery from crashes from the same code that crashed. That's why in OTP Supervisors are in the shape of a tree, each level is responsible for its children and only its children. If you need control on some process tree, you start another supervisor to supervise it and so on. The same goes for the VM: if you need to supervise the VM, you start an external process to check its status. A crashed process is better than a process that misbehaves. Non locality of error handling is the only way to be really fault tolerant.
- walterstucco 7y agoIs there a VM that does not crash in case of a catastrophic event? For example: what happens if I run this code? public class Main { public static void main(String[] args) { Object[] o = null; while (true) { o = new Object[] {o}; } } } What happens if there is a bug in some JNI code that cause a segfault? What Erlang programming style tries to teach is not to avoid crashes by being very defensive and trying to prevent every possible error condition (it's impossible), but to detect them by being fault tolerant and restart the process from a good state.