Dmytro gives a good summary Dmytro Sirenkos answer to How does Erlangimplements preemptive scheduling with one OS thread Example in C would bemuch appreciated.As he says the basic idea is that the interpreter in the Beam virtual machineis running an Erlang program including all of its processes. An instance ofthe Beam VM running in an OS process is a u201cnodeu201d in Erlang parlance. Becausethe Beam is running the user program it can switch from one user Erlangprocess to another without the cooperation of the user code.The beam does not use a timer for switching between Erlang processes. Ratherit uses a number of interpreted operations function calls as a kind ofscheduling quantum it will run one Erlang process for a number of functioncalls then when the function call counter expires it will run anotherprocess and so on. The Erlang folks refer to the function calls being countedas u201creductionsu201d because they were basing the idea off of a Prologimplementation back when they were first designingbuilding the language.Note that because there are no loops in Erlang you have to use recursivecalls to do anything for a long time so a process will always eitherterminate or use up its function call allowance. There are some gotchasparticularly if you write your own NIFs which are C code functions you canwrite to extend the Beam u2023 since you write them they can be uncooperative.It looks very like an OS in that the Beam VM maintains ready queues etc. forErlang processes. That way multiple Erlang processes are mapped onto a singleOS thread a thread running the Beam VM interpreter.Note that itu2019s more complicated than that now The Beam VM is multithreaded.Erlang supports SMP by having an OS thread per core running the Erlangscheduler each core counting reductions as described above. A cool thingabout the SMP support is that actors can migrate from core to core i. e. theErlang runtime does load balancing by allowing low load schedulers to stealprocesses from highly loaded Erlang schedulers on other cores.Robert Virding gives a little tour in a video called A Hitchhikers Tour of theBeam a bit under an hourAn observation that Virding makes in the video is that beam is very like an OSin many respects. This makes sense given its original mission to support softrealtime concurrent software embedded in a range of devices. They wantedconsistent semantics in concurrent and distributed applications and the onlyway to guarantee that across various operating environments was to implementthe semantics themselves in their own runtime. Recall that this was in the1980s so there was even less consistency in thread and processimplementations before pthreads even and pthreads has a lot ofimplementation defined behaviors. The Beam does its own networking too ofcourse and there is an Erlang equivalent of the portmapper for distributedapplications.If you want to know more there is the Beam Book happitheBeamBook whichdocuments the Erlang run time system and links into the source code. You candownload the PDF of the book here happitheBeamBook and note Chapter 11Scheduling. The book comes with C code if you download the source.You can also download the source code for the current release of Erlang fromthe Erlang web site Erlang Programming Language and look at the actual Ccode that implements the erts Erlang runtime system and OTP in the mostrecent release.A colleague of mine used some of the Beam Book and associated Beam code as acase study in a special topics course on runtime systems he taught last fall.I understand it went reasonably well based on a couple conversations I hadwith him and a grad student who was in the course. Warning I asked about thereadability of the C code and my colleague said it was good code written byprofessionals for a performant system i. e. it was not written for pedagogyand some of the students were a bit over their heads. But itu2019s there and theBeam Book can give you the highlights. Iu2019m hoping to find some time to wade inthere myself