160 likes | 316 Views
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!?. McErlang.
E N D
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!? McErlang Message passing guarantees Communication with dead processes Dropping messages A Semantics for Distributed Erlang Pitfalls A More Accurate Semantics for Distributed Erlang Programming Distributed Erlang Applications: Pitfalls and Recipes
{P1,5} 7 P2 Talking to the Dead erlang:process_flag(trap_exit,true), Pid = spawn_link(N2,m,addTwo,[]), Pid ! {self(),5}, receive N -> io:format(“~p\n”,[N]) end, N1 P1 5+2 N2 -module(m). addTwo()-> receive {Pid,Num} -> Pid ! Num + 2 end, addTwo().
{‘EXIT’,P2,terminated} P2 Talking to the Dead N1 P1 receive {‘EXIT’,Pid,Reason} –> ok end, N2
{P1,5} 10 ?? Talking to the Dead Pid ! {self(),5}, receive N -> io:format(“~p\n”,[N]) end, N1 P1 5*2 N2 -module(m2). mulTwo()-> receive {Pid,Num} -> Pid ! Num * 2 end, mulTwo().
Behind the scene • N2 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
1 2 3 … Losing messages 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(). N1 N2 P1 P2 1 2 3 4 5 6 7 8 9 10 11 27 28 29 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29
Behind the scene • N1 and N2 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 P2 N2 world P1 N1 world hello hello world N3 P3 world hello
Distributed communication P2 N2 P1 N1 world world P3 hello N3 P3 hello world
Behind the scene • Only one (TCP-)connection between N1 and N2 • 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
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!)