[erlang-questions] non-FIFO behavior in process mailboxes?

[Ulf Wiger]

You seem to have a race between the messages sent from the client and the ones the server sends to itself.

Bear in mind that the client doesn't yield after send, add SMP to the mix and you cannot know whether that server consumes the first message before the client sends its 

BR,
Ulf W

Ulf Wiger, Feuerlabs, Inc.
http://www.feuerlabs.com

22 apr 2012 kl. 18:25 skrev Michael Turner <michael.eugene.turner@REDACTED>:

> When the code listed below executes with the first io:format call
> commented out, it breaks, reporting:
> 
> ** exception error: no match of right hand side value []
>     in function  wg:init/0
> 
> When I don't have it commented out, it works (sort of), writing
> 
>  val_for (P)=[]
>  val_for (P)=2
>  ok
> 
> Here's the code:
> -----
> 
> -module(wg).
> -export ([init/0, be/2]).
> 
> val_for (P) ->
>    P ! {tell, self(), val},
>    receive
>        {Val, for, P} -> Val
>    end.
> 
> be (Arg, Val) ->
>    receive
>        [H|T] ->
>            self() ! T,
>            self() ! H,
>            be (Arg, Val);
>        [] ->
>            be (Arg, Val);
>        {tell, X, val} ->
>            X ! {Val, for, self()},
>            be (Arg, Val);
>        {set_arg_to, A} ->
>            be (A, Val);
>        {set_val_to, V} ->
>            be (Arg, V)
>    end.
> 
> init() ->
>    P = spawn (wg, be, [[],[]]),
>    P ! [{set_arg_to, 1}, {set_val_to, 2}],
> %   io:format ("val_for (P)=~p~n", [val_for (P)]),
>    2 = val_for (P),
>    io:format ("val_for (P)=~p~n", [val_for (P)]),
>    ok.
> -----
> 
> This is R14B on Windows XP. Haven't tried it elsewhere yet.
> 
> Seeing this really messes with my mental model of process mailboxes.
> With the first io:format call commented out, I think process P should
> be seeing messages queued up in the following order:
> 
>  [{set_arg_to, 1}, {set_val_to, 2}]
>  [{set_val_to, 2}]
>  {set_arg_to, 1}
>  []
>  {set_val_to, 2}
>  {tell, X, val}
> 
> And shouldn't this mean that Val = 2 in process P when the {tell, X,
> val} message reaches P? As I interpret Armstrong pp.145-6, since
> matches are guaranteed in this case, there's no save queue activity;
> since there's no "after" close, the timer is irrelevant; so you should
> get pure FIFO behavior, right?
> 
> -michael turner
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions