06svenss

Download
Share  Add to  Flag Embed
Uploaded from authorPOINTLite
Views:
 
Category: Entertainment
     
 
License:   All Rights Reserved

Presentation Description

No description available.

Comments

Presentation Transcript

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

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!?: 

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 Communication with dead processes Dropping messages

Talking to the Dead: 

Talking to the Dead N1 N2 P1 erlang:process_flag(trap_exit,true), Pid = spawn_link(N2,m,addTwo,[]), -module(m). addTwo()-> receive {Pid,Num} -> Pid ! Num + 2 end, addTwo(). Pid ! {self(),5}, receive N -> io:format(“~p\n”,[N]) end, 5+2

Talking to the Dead: 

Talking to the Dead N1 N2 P1 receive {‘EXIT’,Pid,Reason} –> ok end,

Talking to the Dead: 

Talking to the Dead N1 N2 P1 -module(m2). mulTwo()-> receive {Pid,Num} -> Pid ! Num * 2 end, mulTwo(). Pid ! {self(),5}, receive N -> io:format(“~p\n”,[N]) end, 5*2

Behind the scene: 

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: 

Losing messages N1 P1 N2 P2 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(). 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 1 2 3 4 5 6 7 8 9 10 11 27 28 29

Behind the scene: 

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: 

Distributed communication N1 P1 N2 P2 N3 P3 hello world world hello world world hello

Distributed communication: 

Distributed communication N1 P1 N2 P2 N3 P3 hello world world P3 hello world

Behind the scene: 

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: 

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: 

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!: 

Survey!

Summary: 

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: 

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