* Process: an entity that exists for a certain time, 
	 is evaluating a function,
	 has a state,
	 can communicate with other processes.

Process has a unique id. A process can obtain its own pid using
"self/0". 

Creation:
	spawn/3 
		spawn(Module, Function, [e1,...,ek])
			Effect: Spawn a new process which evaluates
				Module:Function(e1,...,ek)
				on the same node as the spawning
				process. 
				This is the initial call of the new
				process. 
				
				But the spawning process does not wait
				for the call to complete.
			Value:	PID of the new process.
	spawn/4
		spawn(Node, Module, Function, [e1,...,ek])
			Effect: Spawn a new process on the specified
				node. 
	spawn_link/3
		like spawn/3, but link the processes.
	spawn_link/4
		like spawn/4, linking the processes.

Processes communicate through signals: Messages and Exit signals. 
Exit signals: sent on termination of a process, and may cause abrupt
	      termination of others. 
Messages:     sent by *send expression*. reception by evaluating a
	      *receive* expression.

* Process Names
Each node maintains a registry of process names. Names are atoms, and
can be used instead of PID when sending messages.
	register/2
		register()
	whereis/1
	unregister/1
	registered/0
* Linked Processes
If P and Q are linked processes, when either of them exits, an exit
signal is sent to the other.

If P<->Q and P<->R, then when R exits, Q may exit abruptly.

In addition to spawn_link, we can use link/1 to set up a link between
two processes. 

If Q calls link(R), and if R is running, then Q<->R. link/1 is useful
to create links when Q is not the spawning process of R.

* Completion of Processes and Exit signals.
A process may complete
	Evaluation of the top-level expression completes normally. 
	Reason = normal
	
	Abruptly with *exit reason* R. Then Reason = R.

	Abruptly with a throw term. Reason = nocatch.

	receiving an exit signal from a linked process. 

** Sending exit signals explicitly
exit/2 
       exit(P2, Reason)

** Receiving an exit signal
A process P is trapping exits if trap_exit[P] is true.

	If the receiver is trapping exits, the exit reason of the
	sender is placed on the message queue of the receiver.

	the exit reason is "normal", nothing happens.

	Otherwise, the receiving process completes.

* Communicating by Messages

** Message: any Erlang Term

** Sending:
	PID ! Message
	registeredName ! Message
	{Pid, Node} ! Message
	{registeredName, Node} ! Message

	The message has no information about the sender. You can
	design a message with the sender id as part of it, as in

	RECEIVERPID ! {self(), hello}

	Note that self() is evaluated eagerly, so it evaluates to the
	sender's PID.

** Reception:
	receive
		Pattern1 [when Guard1] -> B1;
		...
		PatternN [when GuardN] -> BK;
	[after 
	       E -> BM]
	end

	When there are messages in the mailbox, each message is
	matched in order of arrival, against the patterns. The first
	message that matches some pattern is removed and the
	corresponding BI expression evaluated.

	If no message has arrived, then execution suspends.

	Timeouts:

** Order of Messages
	If P sends M1 and M2 to Q in that order, then M1 is never
	delivered after M2.  

	Note that if P sends MQ to Q and MR to R, then there is
	nothing guaranteed about the order of delivery of MQ and MR.

** Signals
** Order of Signals
	If a signal s is sent to P, and if P has completed, then s
	will never  arrive at P. If the signal is a link request, it
	trigger other signals.
	
	If P sends s1 and s2 to Q in that order, s1 is never delivered
	after s2. 

** Arrival of signals
If P receives a signal
	If P is running: signal is 
		a message M: M is placed at the end of
		message_queue[P].

		exit signal with sender Q: flag