[erlang-questions] Message order and exit(Reason)

[Rickard Green]

Dmitrii Dimandt wrote:
>
> The question is as following: Assume we have processes A and B which
> are linked. Process's A flag trap_exit is set to true. Let B process
> send a msg to A and then exit:
>
> PidA ! 'msg',
> exit(reason).
>
> What I wanna know if we can be shure that the process A will receive
> 'msg' and only after It {'EXIT', Pid, reason} will come ?

The order is guaranteed to be preserved here.

> Can
> we predict the ordering of msgs? I can't found any proofs in
> documentation, but I guess that it will work that way, but I need some
> proofs. Don't want to have race condition here.
>

Unfortunately our documentation lacked this information. In R16 the 
following chapter will be part of the ERTS User's guide.

Cut from ERTS-5.10 User's Guide:
>
> 1 Communication in Erlang
>
> Communication in Erlang is conceptually performed using asynchronous signaling. All different executing entities such as processes, and ports communicate via asynchronous signals. The most commonly used signal is a message. Other common signals are exit, link, unlink, monitor, demonitor signals.
>
> 1.1  Passing of Signals
>
> The amount of time that passes between a signal being sent and the arrival of the signal at the destination is unspecified but positive. If the receiver has terminated, the signal will not arrive, but it is possible that it triggers another signal. For example, a link signal sent to a non-existing process will trigger an exit signal which will be sent back to where the link signal originated from. When communicating over the distribution, signals may be lost if the distribution channel goes down.
>
> The only signal ordering guarantee given is the following. If an entity sends multiple signals to the same destination entity, the order will be preserved. That is, if A send a signal S1 to B, and later sends the signal S2 to B, S1 is guaranteed not to arrive after S2.
>
> 1.2  Synchronous Communication
>
> Some communication is synchronous. If broken down into pieces, a synchronous communication operation, consists of two asynchronous signals. One request signal and one reply signal. An example of such a synchronous communication is a call to process_info/2 when the first argument is not self(). The caller will send an asynchronous signal requesting information, and will then wait for the reply signal containing the requested information. When the request signal reaches its destination the destination process replies with the requested information.
>
> 1.3  Implementation
>
> The implementation of different asynchronous signals in the VM may vary over time, but the behavior will always respect this concept of asynchronous signals being passed between entities as described above.
>
> By inspecting the implementation you might notice that some specific signal actually gives a stricter guarantee than described above. It is of vital importance that such knowledge about the implementation is *not* used by Erlang code, since the implementation might change at any time without prior notice.
>
> Some example of major implementation changes:
>
>     As of ERTS version 5.5.2 exit signals to processes are truly asynchronously delivered.
>     As of ERTS version 5.10 all signals from processes to ports are truly asynchronously delivered.
>

Richard Carlsson wrote:
> The only place I seem to find this actually described is in the old
> (never finished) Standard Erlang Specification Draft by Barklund and
> Virding. In brief, Thomas is right: with regards to propagation and
> order, exit messages are handled like regular messages. In fact, both
> are instances of what the spec calls Signals, and the ordering
> guarantees are valid for all Signals, not just messages.

The wording in 1.1 above is more or less "stolen" from the 
Barklund/Virding spec <http://www.erlang.org/download/erl_spec47.ps.gz>. 
Unfortunately the spec was never completed. I find the spec really 
valuable. Hopefully, we will some day find the time to update and finish 
it. Perhaps we could get some help from the original authors; hint hint :-)

Regards,
Rickard
-- 
Rickard Green, Erlang/OTP, Ericsson AB.