They are lost. New instance of this process will have new Pid. There are no
built-in store-and-forward features in Erlang, but they can be implemented
by a proxy process. But I never had a need to do that in all of my
projects. What is your use case?
On 17 May 2013 08:18, <yashgt> wrote:
> If a process crashes and is restarted by the supervisor, what happens to
> the messages that were sent to the process after it crashed and before it
> restarted? Are they collected and stored somewhere and are they sent to the
> process when it is ready to receive?
> erlang-questions mailing list
> http://erlang.org/mailman/listinfo/erlang-questions >
On Fri, May 17, 2013 at 06:17:54AM +0000, yashgt wrote:
} If a process crashes and is restarted by the supervisor, what
} happens to the messages that were sent to the process after it
} crashed and before it restarted?
On Fri, May 17, 2013 at 11:09 AM, Jonathan Schneider
> > "Sending a message to a pid never fails, even if the pid
> > identifies a non-existing process."
> The documentation could be clearer. It means never causes an error for the
Yes - *sending* messages always works if you have a valid Pid. This does
not mean that
*receiving* the message succeeds.
Suppose the Pid refers to a process on a remote machine. When you send the
remote process might exist. But the remote machine might die while the
message is in transit
between the machines.
Failure of a remote process can be detected by linking to the process. If
the process you have linked to
dies you'll be send an exit signal.
Receiving a message is a somewhat vague idea. When you send a message to a
it gets put in the mailbox of the receiving processes (assuming the
receiving process has not died).
The word "receiving" might mean "put in the receives mailbox" or "evaluates
one of the receive
clauses in a receive statement."
If you want to really know that a message was received and acted upon, you
need to send a confirmation
message back the the sender, when you get this message you'll know that the
processed by the receiver. If you also link to the process you'll get an
error signal back if the process fails.
So basically you link to the remote process, send it a message and you'll
either get a reply
or an exit signal back.