What are Erlang processes behind the scenes?

I've got very limited knowledge about Erlang, but as far as I understand, it 开发者_如何学编程can spawn "processes" with a very low cost.

So I wonder, what are those "processes" behind the scenes?

Are they Fibers? Threads? Continuations?

They are Lightweight Processes.

Also see my question Technically why is processes in Erlang more efficient than OS threads.

Also, from the Erlang doc:

Erlang processes are light-weight (grow and shrink dynamically) with small memory footprint, fast to create and terminate and the scheduling overhead is low.

Source: http://www.erlang.org/doc/reference_manual/processes.html

You might also want to have a look to this:

http://www.defmacro.org/ramblings/concurrency.html

When talking about Erlang processes, it says:

Erlang processes are lightweight threads. They're very cheap to start up and destroy and are very fast to switch between because under the hood they're simply functions. A typical Erlang system running on a modern desktop computer can switch between many tens of thousands such processes. Processes are switched every couple of dozen function calls which makes switches less granular but saves a tremendous amount of time normally wasted on context switching.

I haven't found a definitive source, but from what I understand:

• There is a scheduler (eg or multiple schedulers that act cooperatively) that determines which erlang process to launch on which OS thread.

• These processes have a growable stack (perhaps a preamble in each functions that allocates stack if needed) so they don't consume too much memory unless they need it.

• They yield back to the scheduler depending on whether they are waiting on data or have executed for a sufficient amount of time (maybe preamble code in some functions checks to see how much time has elapsed). Unlike threads, they don't get preempted?

• Each process allocates memory from different pages or from a different allocator, so it is not possible to share memory (in similar way that OS processes avoid sharing memory).

• Presumably also having separate allocators or pages per erlang process would also help with garbage collection, and in the case that the process ends, then the pages can be returned without having to do any garbage collection: http://prog21.dadgum.com/16.html

Basically they are Threads ;) One address space for them.