[erlang-questions] Semantics of send

[Joe Armstrong]

On Wed, Apr 28, 2010 at 3:49 PM, Johan Montelius <johanmon@REDACTED> wrote:
>
>
>>>> to_a_or_to_ab_or_to_none(A, B) ->
>>>>    A ! foo,
>>>>    B ! bar,
>>>>    crash().
>
> On Wed, 28 Apr 2010 14:09:38 +0200, Dmitry Belyaev <rumata-estor@REDACTED>
> wrote:
 >
>> Maybe I was too hurry to answer.
>>
>> http://erlang.org/doc/reference_manual/processes.html#id2279644
>> Message sending is asynchronous and safe, the message is guaranteed to
>> eventually reach the recipient, provided that the recipient exists.
>
> Yes, according to the Reference Manual, messages will arrive (provided that
> A and B exists). This is probably also true if A resides on the same node as
> the sender. However If the sender does not reside on the same node things
> are not that simple.
>
> To start with we could have a temporary network problem causing the message
> foo to be lost (it is in the senders buffer until it gives up and throws the
> message away). The first send operation (as far as I know) does not wait for
> the foo message to be acknowledged and continues with sending bar to B.
>
> Another problem is if the foo message is placed in the out buffer waiting to
> be sent and bar is placed in another out buffer. What if bar is sent and
> then the sender node crashes.
>
> Maybe the reference manual should say: Message sending is asynchronous, the
> message is guaranteed to
>  eventually reach the recipient, provided that the recipient exists and
> there is no problem.
>
> Is this the proper description of send?


Sort of. It depends upon which level of abstraction you are talking
about - as a first approximation its ok -
but if you dig under the surface you'll find some problems.

A guarantee is only any good if there is a method for determining if
what you want has happened or not.

The message could reach the recipient but you might never know.

The only way to know is to send a confirmation back, you might not get
the confirmation
because of a machine failure or communication failure. So you can
never confirm what happened.

- -- 000 ---

At the point in time when A sends the message B is alive.

B is on a different machine.

Just before the message was supposed to be delivered to B - B
terminates normally.
In this case there is "no problem" - exit(normal) means I'm
terminating and there is no problem.
But the message does not reach the recipient.

Even if the message *is* received by the recipient this is no
guarantee that the recipient
does anything sensible with the message. Immediately after the message
is received the process might
die for a totally unrelated reason. If the sender needed to know that
the receiver had not only received the
message but done something sensible with it it would have to send back
a confirmation message.

"What happens if the confirmation message isn't received," asked the
Byzantine General ..."send a confirmation
of the confirmation ..."

I guess an exact description of the semantics of send would involve a
model of what A believes about the world
and what B believes about the world, together with a state machine.
A's belief as to whether B is alive and has
received a message has nothing to do with whether B actually *is*
alive. A only knows about how B *was* not
how B *is* (based on the last message sent by B to A). In such a model
you'd also have to model time.
Where is the message when its in transit before it gets in the
mailbox. Is TCP reliable, in the absence of
a socket error and given that we have written all data to a socket,
can we assume that the data is read from the socket?

I have no idea what the answers to these questions are - pragmatically
I mostly use a "if you want to guarantee that a message is processed,
send back a reply after the procssing has worked" style of
programming. Then I use
links as a "catch all" - an invariant to kill off processes that have
died. Links between nodes are ultimately are
layered on top of messaging - so even if a process dies, you cannot
assume the exit will always be delivered.

I think it's valid to assume that between any two processes if you
send a sequence of message to a process and
get a sequence of replies that the message are processed in-order, so
it should suffice to check the first and last message for liveness and
assume that all the ones in the middle were OK.

/Joe







>
>  Johan
>
>
>
> --
> Dr Johan Montelius
> Royal Institute of Technology - KTH
> School of Information and Communication Technology - ICT
>
> ________________________________________________________________
> erlang-questions (at) erlang.org mailing list.
> See http://www.erlang.org/faq.html
> To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED
>
>