9

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?

Roger Johansson
  • 22,764
  • 18
  • 97
  • 193
  • related: http://stackoverflow.com/questions/1934707/what-other-systems-beside-erlang-are-based-on-green-processes – jldupont May 07 '10 at 12:46
  • related: http://stackoverflow.com/questions/1947180/whats-the-difference-between-green-threads-and-erlangs-processes – jldupont May 07 '10 at 12:46

4 Answers4

4

They are Lightweight Processes.

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

Community
  • 1
  • 1
Jonas
  • 121,568
  • 97
  • 310
  • 388
3

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.

Roberto Aloi
  • 30,570
  • 21
  • 75
  • 112
  • So how does this differ from fibers? – Roger Johansson May 07 '10 at 16:31
  • For example, Ruby Fibers can't run simultaneously on different cores/CPUs (as far as I know, correct me if I'm wrong), while Erlang is very good at that. – Roberto Aloi May 07 '10 at 17:46
  • Isn't that more of a Ruby limitation? You can create fibers from/in threads in win32. and thus it shouldn't be any problem to make them run on multiple cores? – Roger Johansson May 08 '10 at 05:27
  • I guess you can run fibers on multiple cores, if the threads are preemptive. I was also reading the follwing (http://ulf.wiger.net/weblog/2008/02/06/what-is-erlang-style-concurrency/). Looks interesting. – Roberto Aloi May 08 '10 at 11:33
  • Also good explanation at the top of http://www.erlang.org/doc/getting_started/conc_prog.html – pevik Sep 19 '13 at 05:13
1

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

mathin
  • 11
  • 1
-10

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

Kijewski
  • 25,517
  • 12
  • 101
  • 143
TomTom
  • 61,059
  • 10
  • 88
  • 148
  • No they aren't. Threads are much too heavyweight to implement Erlang processes. (I didn't downvote, btw.) – Marcelo Cantos May 07 '10 at 11:23
  • So they are totally emulated by timesharing one thread? Sorry, that sounds ridiculo9us inefficient in times where computers have more than one core ;) – TomTom May 07 '10 at 11:50
  • Erlang SMP is one thread per CPU core. The Erlang VM provides each process with an isolated address space, ipc and timesharing. – cthulahoops May 07 '10 at 12:25
  • No. Fibers use cooperative multitasking: when one fiber reaches a good stopping point, it explicitly yields control, allowing another fiber to run on the same core. Erlang processes are more like green threads: http://en.wikipedia.org/wiki/Green_threads – Warren Young May 07 '10 at 15:15
  • Also, threads are pretty inefficient. Each one requires a separate fixed-size stack, for one thing, typically a few MB. That means only 1024 threads per few GB of RAM in the machine, or you get swapping, which gets *really* inefficient. You can run many thousands of Erlang processes in a few GB. – Warren Young May 07 '10 at 15:17
  • @Warren: You can run millions in few GB. – Hynek -Pichi- Vychodil May 10 '10 at 01:26