Slideshare.net (beta)

 

All comments

Add a comment on Slide 1

If you have a SlideShare account, login to comment; else you can comment as a guest


Showing 1-50 of 0 (more)

06svenss

From guest91c436, 9 months ago

200 views  |  0 comments  |  0 favorites  |  3 downloads
 

Groups / Events

 

 
Embed
options

More Info

This slideshow is Public
Total Views: 200
on Slideshare: 200
from embeds: 0

Slideshow transcript

Slide 1: 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

Slide 2: Two Papers One Talk!? McErlang Communicatio Message Dropping A Semantics for n with dead messages passing Distributed Erlang guarantees processes Pitfalls A More Accurate Programming Distributed Semantics for Erlang Applications: Distributed Erlang Pitfalls and Recipes

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

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

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

Slide 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

Slide 7: Losing messages snd(Pid,N)-> rcv()-> Pid ! N, receive N -> io:format(“~p “,[N]), io:format(“~p “,[N]), timer:sleep(5000), end, snd(Pid,N+1). rcv(). N1 N2 P1 P2 123… 1 2 3 4 5 6 7 8 9 10 123 456 7 8 9 10 11 27 28 29 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29

Slide 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

Slide 9: Distributed communication P2 N2 world P1 N1 world hello hello world N3 P3 world hello

Slide 10: Distributed communication P2 N2 P1 N1 world world P3 hello N3 P3 hello world

Slide 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

Slide 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

Slide 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

Slide 14: Survey!

Slide 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?

Slide 16: A message from Lars-Åke • He is at home, working on a new runtime Erik system • He has not figured out the complete Hello world! semantics, yet! (or will it be World Hello!)