Process-level isolation separates concurrent BEAM processes so they share no memory and a crash in one does not directly corrupt another. This turns concurrency into a practical fault-tolerance mechanism: failures can be confined while most of the system continues operating. section 5.1 section 8.0
The isolation model provides several operational benefits:
- Limits an unhandled exception to one process or a small related group instead of taking down unrelated request handlers, jobs, or the server. section 5.1 section 8.0
- Prevents crashed processes from leaving shared memory garbage that corrupts another process. section 8.2
- Runs many lightweight VM-managed processes inside one OS process, with schedulers distributing execution across available CPU cores. section 5.1
- Requires explicit failure detection and recovery because clients cannot use services provided by a process that has stopped. section 8.2
A crashing process leaves another process running
One spawned process starts a second process, then raises an exception. The second process still prints its completion message, and the interactive shell continues running. In a to-do system, the same boundary lets one to-do server fail without stopping other lists or cached reads. section 8.2
Temporary workers preserve broader availability
A demand-started to-do server can use GenServer with restart: :temporary. A crash stops that worker without restarting it or causing repeated child failures to take down the wider cache; the next use starts it again. section 9.2.4
Visualizes one BEAM OS process using a few scheduler threads to run a large number of isolated processes. section 5.1
