[Ericsson AB]

5 Processes

5.1 Creation of an Erlang process

An Erlang process is very lightweight compared to most operating system threads and processes but it is always important to be aware of its characteristics. Each Erlang process takes a minimum of 318 words of memory for heap, stack etc. The heap is increased in Fibonacci steps depending on data created by the program. The stack is increased by means of nested function calls and a non terminating recursive call will increase the stack until all memory resources are exhausted and the Erlang node will be terminated. The latter means that you need to write tail-recursive process loops.

DO

   loop() -> 
    receive
      {sys, Msg} ->
            handle_sys_msg(Msg),
            loop();
      {From, Msg} ->
            Reply = handle_msg(Msg),
            From ! Reply,
            loop()
    end.
    

DO NOT

   loop() -> 
    receive
      {sys, Msg} ->
            handle_sys_msg(Msg),
            loop();
      {From, Msg} ->
            Reply = handle_msg(Msg),
            From ! Reply,
            loop()
    end,
    
    io:format("Message is processed ~n", []).

    %% The last line in the example above will never be executed and
    %% will eventually eat up all memory.
      
    

digger
"Don't buy too many spades!"

A good principle when deciding which processes you need is to have one process for each truly parallel activity in the system. Consider the analogy where you have three diggers digging a ditch, and to speed things up you buy a fourth spade. Alas that will not help at all as a digger can only use one spade at a time.

5.2 Process messages

All data in messages between Erlang processes is copied, with binaries between processes at the same node as the only exception. Binaries are shared between Erlang processes and only the reference to a binary is copied.

When a message is sent to a process on another Erlang node it is first encoded to the Erlang External Format and then sent on a tcp/ip socket. The receiving Erlang node decodes the message and distributes it to the right process.

5.2.1 Binaries

As there is no copying when sending a binary to a process on the same node, it might be relevant to have your message as a binary. Use binary form in messages if the cost for encoding/decoding to/from binary form can be expected to be less than the gain of transfering in binary form. Cases where binary form could be advantageous are when:

5.2.2 Atom vs Strings

It is more efficient to send atoms than strings. However it is more inefficient to convert all strings with list_to_atom before sending them, then to send the string as it is. The best way is to always use atoms if possible.

DO

%% Send message on the following format    
{insert, {Name, Location}}
{remove, Name}
{retrieve_location, Name}
      

DO NOT

%% Don't send message on the following format    
{"insert", {Name, Location}}
{"remove", Name}
{"retrieve_location", Name}
      

Copyright © 1991-2006 Ericsson AB