How is process in elixir different with system thread in other language?

Hi everyone,

I have a question regarding elixir processes. Based on what I read and understand, the process in elixir is extremely lightweight and efficient compared with Thread in other languages. But how can elixir/erlang VM can handle with problem like context switching so that it can execute many processes concurrently ?
I am from Java background and for Java application server like Tomcat, we have c10k problem when the server will become unresponsive or return error response when it reached around 10k requests. The problem is because thread consume memory and exhaust system memory and the system cannot do extensive context switching anymore.

So how can erlang vm can execute so many processes concurrently ? Is there any article or blog posts that can explain about this ?
Thanks for your help.

1 Like

Here is the basic structure of it (slide from a talk I held):

So at the bottom is the BEAM (Erlang VM) process. This is a normal operating system process like any other.

The BEAM then starts scheduler threads (S1–S4 in the image), by default as many as there are cores in the system. So the system in the image would have a quad core processor. These scheduler threads are normal operating system threads.

The schedulers run BEAM processes (these are where your code is in). These are not operating system processes or threads, they are internal to BEAM. BEAM runs a process on a scheduler thread for a certain amount of time (basically) and then moves it to waiting state and picks up another process to run. In this image, green processes are being executed, blue are waiting for their turn, and grey are waiting for something external, like a database or file read, before they can continue execution.

Why is it fast and light? Because the BEAM processes are internal, they do not need the data structures and memory areas that the operating system allocates for every OS level process and thread. And since they are scheduled internally in the scheduler threads, they do not need the operating system’s context switch. So in the operating system’s view it is running one program continuously without need for switching. The BEAM does not need to support all the use cases an operating system does so it can allocate less memory and have a lighter context switch for its internal processes.


Thank you so much @Nicd This is really what I am looking for. This really makes sense and answer all my question.

1 Like

Also to extend on what @Nicd already said, some even consider the BEAM an operating system in itself.

As far as I know there is even an implementation that is capable of running on top of the XEN virtualization hypervisor without an additional operating system layer


If you know your Java history, back in the 1.1, 1.2 days the JVM used “green threads” which are similar to BEAM processes. The scheduler wasn’t as optimized, and the community wanted native threads to optimize for compute speed.