Erlang is a programming language for building highly parallel, distributed, fault-tolerant systems. This is the second part of a two-part introduction.

1. Distributed Features of Erlang

2. 2
Concurrency
● A deep understanding of concurrency is “hardwired” into our brains
● The world is parallel
● Erlang programs model how we think and interact:
– No shared memory
● People function as independent entities who communicate by sending
messages:
– Erlang is based on pure message passing
– No locking needed
● If somebody dies, other people will notice:
– Processes can be linked together

3. 3
Erlang Processes
● Erlang processes belong to the programming language, not to the OS
– Creating and destroying processes is very fast
– Sending messages between processes is very fast
– Processes behave the same way on all operating systems
– A very large number of processes is feasible
– Processes share no memory and are completely independent
– Creating a process takes 4–5ms
– The only way for processes to interact is through message passing

4. 4
Concurrency Primitives
● Pid = spawn(Fun)
– Create a new concurrent process that evaluates Fun. The primitive
returns the process identifier
● Pid ! Message
– Send Message to the process Pid. The send is nonblocking
(asynchronous). The value of the expression is the message itself.
Therefore, Pid1 ! Pid2 ! ... ! PidN ! M sends M to all mentioned
processes
● receive ... end
– Receive a message according to a pattern.

5. 5
A Simple Example
%% area_server.erl
-module(area_server).
-export([loop/0]).
loop()->
receive
{rectangle, Width, Ht} -> io:format(“A=~p~n”,[Width*Ht]), loop();
{circle, R} -> io:format(“A=~p~n”,[3.14159*R*R]), loop();
Other -> io:format(“Error: ~p~n”, [Other]), loop()
end.
%% Usage:
1> Pid = spawn(fun area_server:loop/0).
<0.36.0>
2> Pid ! {rectangle, 6, 10}.
A=60
{rectangle, 6, 10}

6. 6
Client-server
● Actually, “request-response”
● To receive a response, a request must contain the pid of the requester
● Received responses must be matched with pending requests with the
help of pid's and, if necessary, sequence numbers
● Requests can be disguised as (remote) procedure calls

7. 7
Client-server example
%% area_server_final.erl
-module(area_server_final).
-export([start/0,area/2]).
start() -> spawn(fun loop/0).
area(Pid, What) -> rpc(Pid, What).
rpc(Pid, Request) ->
Pid ! {self(), Request},
receive
{Pid, Response} -> Response
End.
loop() ->
receive
{From, {rectangle, W, H}} -> From ! {self(), W*H}, loop();
%%....
end.

8. 8
Client-server example (cont.)
%% At shell prompt
1> Pid = area_server_final:start().
<0.36.0>
2> area_server_final:area(Pid, {rectangle, 10, 8}).
80

9. 9
Receive with timeout and guards
● receive...end can have and optional after clause that takes Time in
milliseconds and returns an expression if no message is received after
Time. Time can be infinity.
● The receive clause itself can be empty. Good for timers:
sleep(T) -> receive after T -> true end.
● A timeout value can be 0. Good for flushing mailboxes:
flush_mailbox() ->
receive _Any -> flush_buffer()
after 0 -> true
end.
● Any pattern in the receive clause can have a when guard.

10. 10
Example: Timer
-module(timer).
-export([start/2, cancel/1]).
start(Time, Fun) -> spawn(fun()->timer(Time, Fun) end).
cancel(Pid) -> Pid ! cancel.
timer(Time, Fun) ->
receive
cancel -> void
after Time -> Fun()
end.

11. 11
Registered processes
● A pid can be published. A process with a published pid becomes a
registered process.
● register(atom, Pid)
– Register the process Pid with the name atom.
● unregister(atom)
– Remove the registration. If a registered process dies it will be
automatically unregistered.
● whereis(atom) -> Pid | undefined
– Find out whether atom is registered, and if so, what's its Pid
● registered() -> AtomList
– Return a list of all registered processes

12. 12
Registered processes: example
1> Pid = spawn(fun area_server:loop/0).
<0.51.0>
2> register(area, Pid).
True
3> area ! {rectangle, 4, 5}.
A=20
{rectangle, 4, 5}

13. 13
Concurrent Program: a Skeleton
-module(template).
-compile(export_all).
start() -> spawn(fun() -> loop([]) end).
rpc(Pid, Request) ->
Pid ! {self(), Request},
receive
{Pid, Response} -> Response
end.
loop(X) ->
receive
Any -> io:format(“Received: ~p~n”, [Any]),
loop(X) %% Tail recursion becomes a loop!
end.

14. 14
Linking processes
● If a process in some way depends on another, then it may keep an eye
on the health of that second process using links and monitors
● Built-in function (BIF) link(Pid) links processes
● BIF spawn_link(Fun) -> Pid spawns a linked process—to avoid race
conditions
● BIF unlink(Pid) unlinks linked processes
● If A and B are linked and one of them dies, the other receives an exit
signal and will die, too—unless it is a system process
● A system process can trap exit signals
● BIF process_flag(trap_exit, true) makes a process a system process

15. 15
on_exit handler: example
%% If Pid dies, execute Fun in yet another process
on_exit (Pid, Fun) ->
spawn(fun() ->
process_flag(trap_exit, true),
link(Pid),
receive
{'EXIT', Pid, Why} ->
Fun(Why)
end
end).

16. 16
A keep-alive process
%% This function will keep a registered process alive!
keep_alive(Name, Fun) ->
register(Name, Pid = spawn(Fun)),
on_exit(Pid, fun(_Why) -> keep_alive(Name, Fun) end).
%% Unfortunately, this code has a race condition:
%% The new process can dies before the handler is registered!

17. 17
Going distributed
● Distributed programs run on networks of computers and coordinate
their activities only by message passing
● Reasons for having distributed programs:
– Performance
– Reliability
– Scalability
– Support for intrinsically distributed applications (games, chats)
– Fun :)
● Trusted or untrusted environment? Distributed Erlang vs TCP/IP
sockets

18. 18
Development sequence
● Write and test a program in a regular nondistributed Erlang session
● Test the program on several different Erlang nodes running on the
same computer
● Test the program on several different Erlang nodes running on several
physically separated computers either in the same local area network
or anywhere on the Internet

19. 19
A simple key-value server (kvs)
-module(kvs).
-export([start/0,store/2,lookup/1]).
start()->register(kvs, spawn(fun()->loop() end)).
store(Key, Value)->rpc({store, Key, Value}).
lookup(Key) -> rpc({lookup, Key}).
rpc(Q)-> .... %% as defined earlier
loop() ->
receive
{From, {store, Key, Value}} -> put(Key, {ok, Value}),
From ! {kvs, true}, loop();
{From, {lookup, Key}} -> From ! {kvs, get(Key)}, loop()
end.

20. 20
Running locally
1> kvs:start().
True
2> kvs:store({location, joe}, “Stockholm”).
True
3> kvs:lookup({location, joe}).
{ok, “Stockholm”}
4> kvs:lookup({location, jane}).
Undefined

21. 21
A better rpc
● Standard Erlang libraries have packages rpc that provides a number of
remote procedure call services, and global that has functions for the
registration of names and locks (if necessary)
● call(Name, Mod, Function, ArgList) -> Result | {badrpc, Reason}
● For two Erlang nodes to communicate, they must share the same
cookie:
– put the cookie in ~/.erlang.cookie (make it user-readable)
– start Erlang shell with -setcookie parameter
– use erlang:set_cookie(node(), C) BIF

22. 22
Two nodes, same host
astra:~/Erlang/> erl -sname aspera
Erlang (BEAM) emulator version 5.6.5 [source] [async-threads:0] [hipe]
[kernel-poll:false]
Eshell V5.6.5 (abort with ^G)
(aspera@astra)1> kvs:start().
true
---------------------------------------------------------------------
astra:~/Erlang/> erl -sname astra
Erlang (BEAM) emulator version 5.6.5 [source] [async-threads:0] [hipe]
[kernel-poll:false]
Eshell V5.6.5 (abort with ^G)
(astra@astra)1> rpc:call(aspera@astra,kvs,store,[weather,fine]).
true
(astra@astra)2> rpc:call(aspera@astra,kvs,lookup,[weather]).
{ok,fine}

23. 23
Two nodes, two different hosts
● Start Erlang with the -name parameter (not -sname)
● Ensure that both nodes have the same cookie
● Make sure that DNS works
● Make sure that both hosts have the same version of the code that you
want to run
– Simply copy the code
– Use network file system (NFS)
– Use a code server (advanced)
– Use the shell command nl(Mod). This loads the module Mod on all
connected nodes.

24. 24
More distribution primitives
● disconnect_node(Node) -> bool() | ignored
– forcefully disconnects a node
● node() -> Node
– returns the name of the local node
● node(Arg) -> Node
– returns the node where Arg (a PID, a reference, or a port) is located
● nodes() -> [Node]
– returns a list of all other connected nodes
● is_alive() -> bool()
– returns true if the local node is alive

25. 25
Remote spawn
● spawn(Node,Fun) -> Pid
– this works exactly like spawn(Fun)—but remotely
● spawn(Node, Mod, Func, ArgList) -> Pid
– same as above; this function will not break if the distributed nodes
do not run exactly the same version of a particular module
● spawn_link(Node, Func) -> Pid
● spawn_link(Node, Mod, Func, ArgList)

26. 26
A note on security
● Distributed Erlang should be used only in a trusted environment
● In an unstrusted network, use TCP/IP (module gen_tcp) or UDP/IP
(module gen_udp) sockets

27. 27
Using TCP: example 1 (client)
%% socket_example.erl
nano_get_url() -> nano_get_url(“www.google.com”).
nano_get_url(Host) ->
{ok, Socket} = gen_tcp:connect(Host,80,[binary, {packet, 0})],
ok = gen_tcp:send(Socket, “GET / HTTP/1.0rnrn”),
receive_data(Socket, []).
receive_data(Socket, SoFar) ->
receive
{tcp,Socket,Bin} -> receive_data(Socket, [Bin|SoFar]);
{tcp_closed,Socket} -> list_to_binary(reverse(SoFar))
end.
%% On the shell command line:
1> string:tokens(binary_to_list(socket_examples:nano_get_url),”rn”).
%% But of course there is a standard function http:request(Url) !

28. 28
Using TCP: example 2 (server)
%% socket_examples.erl
start_nano_server() ->
{ok, Listen} = gen_tcp:listen (2345, [binary, {packet, 4},
{reuseaddr, true}, {active, true}]),
{ok, Socket} = gen_tcp:accept (Listen),
gen_tcp:close (Listen),
loop (Socket).
loop(Socket) ->
receive
{tcp, Socket, Bin} -> io:format(“~p received~n”, [Bin]),
Str = binary_to_term(Bin), %% unmarshalling
...
gen_tcp:send(Socket, term_to_binary(Reply)),
loop(Socket). %% Tail recursion!
{tcp_closed, Socket} -> io:format(“Socket closed~n”)
end.

29. 29
Programming with files
● Erlang supports (through module file):
– Reading all Erlang terms from a file at once
– Reading Erlang terms from a file one at a time and writing them
back
– Reading files line by line and writing lines into a file
– Reading an entire file into a binary and writing a binary to a file
– Reading files randomly
– Getting file info
– Working with directories
– Copying and deleting files

30. 30
This presentation roughly covers the second 27
pages (of the total of 29
) of
“Programming Erlang. Software for a Concurrent World,” by Joe
Armstrong.