[erlang-questions] : order-preserving send?
Thu Sep 4 09:03:32 CEST 2008
Raimo Niskanen wrote:
> On Thu, Aug 28, 2008 at 03:56:39PM +0200, Hans Svensson wrote:
>> Matthias Lang wrote:
> : :
>>> That misleading and, for practical purposes, wrong.
>>> >From the FAQ:
>>> | 10.9 Is the order of message reception guaranteed?
>>> | Yes, but only within one process.
>>> | If there is a live process and you send it message A and then message
>>> | B, it's guaranteed that if message B arrived, message A arrived before
>>> | it.
>> That is however not true (in the distributed case), it is possible to
>> drop A and then later receive B. The paper 'Programming Distributed
>> Erlang Applications: Pitfalls and Recipes' describes this situation as
>> well as some other quirks:
> I'd say it is true enough. Since for this to happen, the receiving node
> has to be restarted 2 (or was it 3) times to wrap the node incarnation
> counter, and Erlang was designed under the assumption that the distributed
> application must detect the first node restart anyway and handle it.
> Plus, it is a new receiving process that receives B. A went to the old
> receiver. The horrible situation where you send A, B, C to a reciever
> and B vanishes can not happen. The receiver gets all before a certain
> point or all after.
Nah, the restarting was for getting back the exact same Pid (and you
have to restart 3 times ;-) ).
In order to only receive B, it is enough to pull out the ethernet cable
(or equivalent) and put it back with some (un)fortunate timing. It is
still the same receiving process!
> You are supposed to use links or monitors if you are interested
> in the other side's death.
That is the answer to just about anything, and it works in this case as
well, since the network interruption can be detected.
More information about the erlang-questions