Transcript Programming Distributed Erlang Applications: Pitfalls and

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
Communicatio
Message
Dropping
nmessages
passing
with 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
N1
P1
erlang:process_flag(trap_exit,true),
Pid
! {self(),5},
Pid = spawn_link(N
2,m,addTwo,[]),
receive
N -> io:format(“~p\n”,[N])
end,
{P1,5}
7
N2
-module(m).
addTwo()->
receive {Pid,Num} ->
Pid ! Num + 2
end,
addTwo().
P2
5+2
Talking to the Dead
N1
P1
receive {‘EXIT’,Pid,Reason} –> ok end,
{‘EXIT’,P2,terminated}
N2
P2
Talking to the Dead
N1
P1
Pid ! {self(),5},
receive N -> io:format(“~p\n”,[N]) end,
{P1,5}
10
N2
-module(m2).
mulTwo()->
receive {Pid,Num} ->
Pid ! Num * 2
end,
mulTwo().
??
5*2
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
Losing messages
snd(Pid,N)->
Pid ! N,
io:format(“~p “,[N]),
timer:sleep(5000),
snd(Pid,N+1).
N1
1 2 3
11 12
18 19
25 26
P1
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…
N2
P2
1 2 3 4 5 6 7 8 9 10
11 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
N2
N1
P1
P2
world
world
hello
N3
P3
hello world
world hello
Distributed communication
N2
N1
P1
P2
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
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!)