Erlang is a functional programming language used primarily for building scalable and fault-tolerant systems. One of the key features in Erlang is its concurrency model which relies heavily on message passing between processes. In Erlang, each process has a mailbox and communicates with other processes by sending and receiving messages. However, a process cannot receive messages before it officially starts, as these messages are routed to its unique mailbox which isn't active until the process itself is running.

Understanding Message Passing in Erlang

In Erlang, processes communicate asynchronously via message passing. When you send a message in Erlang, it gets queued in the recipient process's mailbox. A process checks its mailbox in a first-in, first-out (FIFO) order with the receive expression, which matches incoming messages against specified patterns.

The Start of an Erlang Process

When an Erlang process is created using the spawn function, it begins its life cycle. However, its ability to check or receive messages starts only after the process is fully initialized and enters its receive loop. If any message is sent to a process before it reaches its receive loop, those messages simply get queued in the mailbox.

Examples

Consider a scenario where process A spawns process B and immediately sends a message to B:

1-module(example).
2-export([start/0, process_b/0]).
3
4start() ->
5    Pid = spawn(?MODULE, process_b, []),
6    Pid ! {self(), hello},
7    receive
8        {Pid, Response} -> io:format("Received: ~p~n", [Response])
9    end.
10
11process_b() ->
12    receive
13        {From, Msg} -> 
14            io:format("Process B received: ~p~n", [Msg]),
15            From ! {self(), received}
16    end.

In this example, the message {self(), hello} is sent to process B right after it is spawned. Even though it is sent before process B enters the receive block, the Erlang runtime ensures that the message is queued in process B’s mailbox. It will be waiting when B starts receiving.

Situations where Messages are not Received as Expected

1. Wrong Process Identifier (PID)

If you send a message to a non-existing or wrong PID, the message is lost because there are no checks on the existence of a PID when sending a message.

2. Crashed Before Receiving

If a process crashes or terminates before it starts receiving messages or during its processing, any messages in its mailbox are lost.

Summary Table

Additional Considerations

• Mailbox Overflow: If a process does not process its messages quickly enough, the mailbox can grow indefinitely, which may lead to memory issues. Hence, occasionally, it's essential to design back-pressure systems or set limits on mailboxes.
• Monitoring: Processes can monitor each other to detect crashes and handle errors gracefully.
• Timed Receive: Processes can use timed receive to avoid being blocked indefinitely, enhancing the responsiveness of the system.

In conclusion, understanding the nuances of message passing and the lifecycle of Erlang processes is crucial in leveraging the full potential of its concurrency model. By grasping these concepts, developers can build robust and efficient systems that handle various real-time, distributed computing challenges.