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
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<!-- This document was generated using DocBuilder 3.3.3 -->
<HTML>
<HEAD>
<TITLE>Processes</TITLE>
<SCRIPT type="text/javascript" src="../../doc/erlresolvelinks.js">
</SCRIPT>
</HEAD>
<BODY BGCOLOR="#FFFFFF" TEXT="#000000" LINK="#0000FF" VLINK="#FF00FF"
ALINK="#FF0000">
<CENTER>
<A HREF="http://www.erlang.se"><IMG BORDER=0 ALT="[Ericsson AB]" SRC="min_head.gif"></A>
</CENTER>
<A NAME="10"><!-- Empty --></A>
<H2>10 Processes</H2>
<A NAME="10.1"><!-- Empty --></A>
<H3>10.1 Processes</H3>
<P>Erlang is designed for massive concurrency. Erlang processes are
light-weight (grow and shrink dynamically) with small memory
footprint, fast to create and terminate and the scheduling
overhead is low.<A NAME="10.2"><!-- Empty --></A>
<H3>10.2 Process Creation</H3>
<P>A process is created by calling <CODE>spawn</CODE>:
<PRE>
spawn(Module, Name, Args) -> pid()
Module = Name = atom()
Args = [Arg1,...,ArgN]
ArgI = term()
</PRE>
<P><CODE>spawn</CODE> creates a new process and returns the pid.
<P>The new process will start executing in
<CODE>Module:Name(Arg1,...,ArgN)</CODE> where the arguments is
the elements of the (possible empty) <CODE>Args</CODE> argument list.
<P>There exist a number of other <CODE>spawn</CODE> BIFs, for example
<CODE>spawn/4</CODE> for spawning a process at another node.<A NAME="10.3"><!-- Empty --></A>
<H3>10.3 Registered Processes</H3>
<P>Besides addressing a process by using its pid, there are also
BIFs for registering a process under a name. The name must be an
atom and is automatically unregistered if the process terminates:
<P>
<CENTER>
<TABLE CELLSPACING=0 CELLPADDING=2 BORDER=1>
<CAPTION ALIGN=BOTTOM><EM>Name Registration BIFs.</EM></CAPTION>
<TR>
<TD ALIGN="LEFT" VALIGN="MIDDLE">
<CODE>register(Name, Pid)</CODE>
</TD>
<TD ALIGN="LEFT" VALIGN="MIDDLE">
Associates the name <CODE>Name</CODE>, an atom, with
the process <CODE>Pid</CODE>.
</TD>
</TR>
<TR>
<TD ALIGN="LEFT" VALIGN="MIDDLE">
<CODE>registered()</CODE>
</TD>
<TD ALIGN="LEFT" VALIGN="MIDDLE">
Returns a list of names which have been registered using
<CODE>register/2</CODE>.
</TD>
</TR>
<TR>
<TD ALIGN="LEFT" VALIGN="MIDDLE">
<CODE>whereis(Name)</CODE>
</TD>
<TD ALIGN="LEFT" VALIGN="MIDDLE">
Returns the pid registered under <CODE>Name</CODE>, or
<CODE>undefined</CODE> if the name is not registered.
</TD>
</TR>
</TABLE>
</CENTER>
<A NAME="term"><!-- Empty --></A><A NAME="10.4"><!-- Empty --></A>
<H3>10.4 Process Termination</H3>
<P>When a process terminates, it always terminates with an
<STRONG>exit reason</STRONG>. The reason may be any term.
<P>A process is said to terminate <STRONG>normally</STRONG>, if the exit
reason is the atom <CODE>normal</CODE>. A process with no more code to
execute terminates normally.
<P>A process terminates with exit reason <CODE>{Reason,Stack}</CODE>
when a run-time error occurs. See
<A HREF="errors.html#exit_reasons">Error and Error
Handling</A>.
<P>A process can terminate itself by calling one of the BIFs
<CODE>exit(Reason)</CODE>,
<CODE>erlang:error(Reason)</CODE>, <CODE>erlang:error(Reason, Args)</CODE>,
<CODE>erlang:fault(Reason)</CODE> or <CODE>erlang:fault(Reason, Args)</CODE>.
The process then terminates with reason <CODE>Reason</CODE> for
<CODE>exit/1</CODE> or <CODE>{Reason,Stack} for the others</CODE>.
<P>A process may also be terminated if it receives an exit signal
with another exit reason than <CODE>normal</CODE>, see
<A HREF="#errors">Error Handling</A> below.<A NAME="10.5"><!-- Empty --></A>
<H3>10.5 Message Sending</H3>
<P>Processes communicate by sending and receiving messages.
Messages are sent by using
the <A HREF="expressions.html#send">send operator !</A>
and received by calling
<A HREF="expressions.html#receive">receive</A>.
<P>Message sending is asynchronous and safe, the message is
guaranteed to eventually reach the recipient, provided that
the recipient exists.<A NAME="10.6"><!-- Empty --></A>
<H3>10.6 Links</H3>
<P>Two processes can be <STRONG>linked</STRONG> to each other. A link
between two processes <CODE>Pid1</CODE> and <CODE>Pid2</CODE> is created
by <CODE>Pid1</CODE> calling the BIF <CODE>link(Pid2)</CODE> (or vice versa).
There also exists a number a <CODE>spawn_link</CODE> BIFs, which spawns
and links to a process in one operation.
<P>Links are bidirectional and there can only be one link between
two processes. Repeated calls to <CODE>link(Pid)</CODE> have no effect.
<P>A link can be removed by calling the BIF <CODE>unlink(Pid)</CODE>.
<P>Links are used to monitor the behaviour of other processes, see
<A HREF="#errors">Error Handling</A> below.<A NAME="errors"><!-- Empty --></A><A NAME="10.7"><!-- Empty --></A>
<H3>10.7 Error Handling</H3>
<P>Erlang has a built-in feature for error handling between
processes. Terminating processes will emit exit signals to all
linked processes, which may terminate as well or handle the exit
in some way. This feature can be used to build hierarchical
program structures where some processes are supervising other
processes, for example restarting them if they terminate
abnormally.
<P>Refer to OTP Design Principles for more information about
OTP supervision trees, which uses this feature.<A NAME="10.7.1"><!-- Empty --></A>
<H4>10.7.1 Emitting Exit Signals</H4>
<P>When a process terminates, it will terminate with an <STRONG>exit
reason</STRONG> as explained in <A HREF="#term">Process
Termination</A> above. This exit reason is emitted in
an <STRONG>exit signal</STRONG> to all linked processes.
<P>A process can also call the function <CODE>exit(Pid,Reason)</CODE>.
This will result in an exit signal with exit reason
<CODE>Reason</CODE> being emitted to <CODE>Pid</CODE>, but does not affect
the calling process.<A NAME="10.7.2"><!-- Empty --></A>
<H4>10.7.2 Receiving Exit Signals</H4>
<P>The default behaviour when a process receives an exit signal
with an exit reason other than <CODE>normal</CODE>, is to terminate
and in turn emit exit signals with the same exit reason to its
linked processes. An exit signal with reason <CODE>normal</CODE> is
ignored.
<P>A process can be set to trap exit signals by calling:
<PRE>
process_flag(trap_exit, true)
</PRE>
<P>When a process is trapping exits, it will not terminate when
an exit signal is received. Instead, the signal is transformed
into a message <CODE>{'EXIT',FromPid,Reason}</CODE> which is put into
the mailbox of the process just like a regular message.
<P>An exception to the above is if the exit reason is <CODE>kill</CODE>,
that is if <CODE>exit(Pid,kill)</CODE> has been called. This will
unconditionally terminate the process, regardless of if it is
trapping exit signals or not.<A NAME="10.8"><!-- Empty --></A>
<H3>10.8 Monitors</H3>
<P>An alternative to links are <STRONG>monitors</STRONG>. A process
<CODE>Pid1</CODE> can create a monitor for <CODE>Pid2</CODE> by calling
the BIF <CODE>erlang:monitor(process, Pid2)</CODE>. The function returns
a reference <CODE>Ref</CODE>.
<P>If <CODE>Pid2</CODE> terminates with exit reason <CODE>Reason</CODE>, a
'DOWN' message is sent to <CODE>Pid1</CODE>:
<PRE>
{'DOWN', Ref, process, Pid2, Reason}
</PRE>
<P>If <CODE>Pid2</CODE> does not exist, the 'DOWN' message is sent
immediately with <CODE>Reason</CODE> set to <CODE>noproc</CODE>.
<P>Monitors are unidirectional. Repeated calls to
<CODE>erlang:monitor(process, Pid)</CODE> will create several,
independent monitors and each one will send a 'DOWN' message when
<CODE>Pid</CODE> terminates.
<P>A monitor can be removed by calling
<CODE>erlang:demonitor(Ref)</CODE>.
<P>It is possible to create monitors for processes with registered
names, also at other nodes.<A NAME="10.9"><!-- Empty --></A>
<H3>10.9 Process Dictionary</H3>
<P>Each process has its own process dictionary, accessed by calling
the following BIFs:
<PRE>
put(Key, Value)
get(Key)
get()
get_keys(Value)
erase(Key)
erase()
</PRE>
<CENTER>
<HR>
<SMALL>
Copyright © 1991-2006
<A HREF="http://www.erlang.se">Ericsson AB</A><BR>
</SMALL>
</CENTER>
</BODY>
</HTML>
|
