Programming Distributed Erlang Applications Pitfalls and Recipes A

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

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

Talking to the Dead N 1 P 1 erlang: process_flag(trap_exit, true), Pid ! {self(), 5}, Pid = spawn_link(N 2, m, add. Two, []), receive N -> io: format(“~pn”, [N]) end, {P 1, 5} 7 N 2 -module(m). add. Two()-> receive {Pid, Num} -> Pid ! Num + 2 end, add. Two(). P 2 5+2

Talking to the Dead N 1 P 1 receive {‘EXIT’, Pid, Reason} –> ok end, {‘EXIT’, P 2, terminated} N 2 P 2

Talking to the Dead N 1 Pid ! {self(), 5}, receive N -> io: format(“~pn”, [N]) end, {P 1, 5} 10 N 2 -module(m 2). mul. Two()-> receive {Pid, Num} -> Pid ! Num * 2 end, mul. Two(). ? ? 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 snd(Pid, N)-> Pid ! N, io: format(“~p “, [N]), timer: sleep(5000), snd(Pid, N+1). N 1 1 2 3 11 12 18 19 25 26 P 1 4 5 6 13 14 20 21 27 28 7 8 9 10 15 16 17 22 23 24 29 rcv()-> receive N -> io: format(“~p “, [N]), end, rcv(). 123… N 2 P 2 1 2 3 4 5 6 7 8 9 10 11 27 28 29

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 N 2 N 1 P 2 world hello N 3 P 3 hello world hello

Distributed communication N 2 N 1 P 2 world P 3 hello N 3 P 3 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 hasworld! not figured out the complete Hello semantics, (or will it be yet! Erik World Hello!)