Programming Distributed Erlang Applications: Pitfalls and Recipes A More Accurate Semantics for Dist

1
Programming Distributed Erlang Applications
Pitfalls and RecipesA 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

2
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 Pitfa
lls and Recipes
3
Talking to the Dead
erlangprocess_flag(trap_exit,true), Pid
spawn_link(N2,m,addTwo,),
Pid ! self(),5, receive N -gt ioformat(p\n,N
) end,
N1
P1
52
N2
-module(m). addTwo()-gt receive Pid,Num -gt
Pid ! Num 2 end, addTwo().
4
Talking to the Dead
N1
P1
receive EXIT,Pid,Reason gt ok end,
N2
5
Talking to the Dead
Pid ! self(),5, receive N -gt ioformat(p\n,N
) end,
N1
P1
52
N2
-module(m2). mulTwo()-gt receive Pid,Num -gt
Pid ! Num 2 end, mulTwo().
6
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

7
Losing messages
snd(Pid,N)-gt Pid ! N, ioformat(p ,N),
timersleep(5000), snd(Pid,N1).
rcv()-gt receive N -gt ioformat(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
8
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

9
Distributed communication
P2
N2
world
P1
N1
world
hello
hello world
N3
P3
world hello
10
Distributed communication
P2
N2
P1
N1
world
world
P3
hello
N3
P3
hello world
11
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

12
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

13
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

14
Survey!
15
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?

16
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!)