[erlang-questions] how are erlang process lightweight?

[Ben Dougall]

On Tuesday, October 3, 2006, at 12:58  pm, Sean Hinde wrote:

> On 3 Oct 2006, at 12:25, Ben Dougall wrote:
>
>> So that seems to be the thing, so far as memory footprint goes: 
>> threads
>> have a stack and that stack is, as usual, made up or an indefinite
>> number of frames -- potentially many/infinite -- grows per new 
>> function
>> call. Whereas Erlang processes are tied very tightly (one to one) to
>> functions, and a function's memory usage amount to one frame of a
>> stack. So an Erlang process is limited to a frame of a stack.
>
> This is where you are going wrong. An erlang function is only related 
> to a process in the sense that processes evaluate functions. Each 
> process has its own stack that can grow/shrink as much as it needs.
>
> It is not nearly as different to pthreads as you describe. The 
> efficiency gains of Erlang are *only* those of being able to optimise 
> process switching and do custom memory management.

I've just coming to that conclusion from Richard's reply, as from what 
he was saying there is not much difference between thread and Erlang 
process memory footprints.

> Erlang processes are actually more akin to UNIX processes as they do 
> not share state. Think of them as exactly like UNIX processes with 
> much less overhead and much nicer message passing.

Yes I understand that. It was how they've ended up so light is what I 
was interested in. And I now realise that it's the fact that it's all 
(the switching etc.) handled in user space by the Erlang system where 
the efficiency/saving comes from. So it's not so much a saving of 
memory space (although I guess there is at least a bit of memory space 
saving) but a saving in the amount of memory-shifting-round that the 
machine needs to do. Less memory-shifting-round is necessary with E.P.s 
than threads.

> Having the flexibility to implement language specific memory 
> management and process switching with custom message passing are big 
> wins until UNIX implements the same things directly. I suspect that is 
> not likely to happen soon.

Right, thanks very much,
Ben.