Programming Distributed Erlang Applications: Pitfalls and Recipes + A More Accurate Semantics for Distributed Erlang Hans Svensson Chalmers University of Technology Lars-Åke Fredlund Universidad Politécnica de Madrid Erlang Workshop, Freiburg, 5 Oct. 2007

Message passing guarantees Two Papers One Talk!? McErlang Pitfalls A More Accurate Semantics for Distributed Erlang A Semantics for Distributed Erlang Programming Distributed Erlang Applications: Pitfalls and Recipes Communicatio n with dead processes Dropping messages

Talking to the Dead N1N1 N2N2 P1P1 erlang:process_flag(trap_exit,true), Pid = spawn_link(N 2,m,addTwo,[]), -module(m). addTwo()-> receive {Pid,Num} -> Pid ! Num + 2 end, addTwo(). P2P2 Pid ! {self(),5}, receive N -> io:format(~p\n,[N]) end, {P 1,5} 5+2 7

Talking to the Dead N1N1 N2N2 P1P1 receive {EXIT,Pid,Reason} –> ok end, P2P2 {EXIT,P 2,terminated}

Talking to the Dead N1N1 N2N2 P1P1 -module(m2). mulTwo()-> receive {Pid,Num} -> Pid ! Num * 2 end, mulTwo(). ? Pid ! {self(),5}, receive N -> io:format(~p\n,[N]) end, {P 1,5} 10 5*2

Behind the scene N 2 was stopped and restarted A new process managed to get exactly the same pid Since the pid data structure is finite, this is expected, however… The magic number is 3! This feature can not be modeled even in the more accurate semantics

Losing messages N1N1 P1P1 N2N2 P2P2 snd(Pid,N)-> Pid ! N, io:format(~p,[N]), timer:sleep(5000), snd(Pid,N+1). rcv()-> receive N -> io:format(~p,[N]), end, rcv() …

Behind the scene N 1 and N 2 was disconnected and later reconnected Easily discovered by using links Never rely on distributed communication without supervision This scenario can be correctly modeled in the improved semantics

Distributed communication N1N1 P1P1 N2N2 P2P2 N3N3 P3P3 hello world hello world world hello

Distributed communication N1N1 P1P1 N2N2 P2P2 N3N3 P3P3 hello world P3P3 hello world

Behind the scene Only one (TCP-)connection between N 1 and N 2 A rather obscure guarantee Not recommended to exploit this guarantee in application, future runtime systems might break it This communication guarantee is not reflected in the semantics, there only the weaker guarantee holds

Practical considerations There is always a difference between any model and the actual runtime system Artifacts of the OTP implementation of the runtime system should not be exploited

Changes in the Semantics New rules for node disconnect Simplified rules for node failure and restart A more compact formulation of fairness Properties of the distributed semantics –Extension –Message reordering and node disconnect –Expressiveness –Finite systems stays finite

Survey!

Summary The possibility of reusing a Pid should not be neglected Distributed communication should always be supervised 3 is quite a small number, is it possible to use a larger number?

A message from Lars-Åke He is at home, working on a new runtime system He has not figured out the complete semantics, yet! Erik Hello world! (or will it be World Hello!)