aboutsummaryrefslogtreecommitdiffstats
path: root/system/doc/reference_manual/processes.xml
diff options
context:
space:
mode:
Diffstat (limited to 'system/doc/reference_manual/processes.xml')
-rw-r--r--system/doc/reference_manual/processes.xml111
1 files changed, 63 insertions, 48 deletions
diff --git a/system/doc/reference_manual/processes.xml b/system/doc/reference_manual/processes.xml
index 95ae0672ec..f656d0318e 100644
--- a/system/doc/reference_manual/processes.xml
+++ b/system/doc/reference_manual/processes.xml
@@ -4,20 +4,21 @@
<chapter>
<header>
<copyright>
- <year>2003</year><year>2013</year>
+ <year>2003</year><year>2015</year>
<holder>Ericsson AB. All Rights Reserved.</holder>
</copyright>
<legalnotice>
- The contents of this file are subject to the Erlang Public License,
- Version 1.1, (the "License"); you may not use this file except in
- compliance with the License. You should have received a copy of the
- Erlang Public License along with this software. If not, it can be
- retrieved online at http://www.erlang.org/.
-
- Software distributed under the License is distributed on an "AS IS"
- basis, WITHOUT WARRANTY OF ANY KIND, either express or implied. See
- the License for the specific language governing rights and limitations
- under the License.
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
</legalnotice>
@@ -32,8 +33,8 @@
<section>
<title>Processes</title>
<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
+ lightweight (grow and shrink dynamically) with small memory
+ footprint, fast to create and terminate, and the scheduling
overhead is low.</p>
</section>
@@ -46,10 +47,10 @@ spawn(Module, Name, Args) -> pid()
Args = [Arg1,...,ArgN]
ArgI = term()</pre>
<p><c>spawn</c> creates a new process and returns the pid.</p>
- <p>The new process will start executing in
- <c>Module:Name(Arg1,...,ArgN)</c> where the arguments is
+ <p>The new process starts executing in
+ <c>Module:Name(Arg1,...,ArgN)</c> where the arguments are
the elements of the (possible empty) <c>Args</c> argument list.</p>
- <p>There exist a number of other <c>spawn</c> BIFs, for example
+ <p>There exist a number of other <c>spawn</c> BIFs, for example,
<c>spawn/4</c> for spawning a process at another node.</p>
</section>
@@ -60,18 +61,25 @@ spawn(Module, Name, Args) -> pid()
atom and is automatically unregistered if the process terminates:</p>
<table>
<row>
+ <cell align="left" valign="middle"><em>BIF</em></cell>
+ <cell align="left" valign="middle"><em>Description</em></cell>
+ </row>
+ <row>
<cell align="left" valign="middle"><c>register(Name, Pid)</c></cell>
<cell align="left" valign="middle">Associates the name <c>Name</c>, an atom, with the process <c>Pid</c>.</cell>
</row>
<row>
<cell align="left" valign="middle"><c>registered()</c></cell>
- <cell align="left" valign="middle">Returns a list of names which have been registered using<c>register/2</c>.</cell>
+ <cell align="left" valign="middle">Returns a list of names that
+ have been registered using <c>register/2</c>.</cell>
</row>
<row>
<cell align="left" valign="middle"><c>whereis(Name)</c></cell>
- <cell align="left" valign="middle">Returns the pid registered under <c>Name</c>, or<c>undefined</c>if the name is not registered.</cell>
+ <cell align="left" valign="middle">Returns the pid registered
+ under <c>Name</c>, or <c>undefined </c>if the name is not
+ registered.</cell>
</row>
- <tcaption>Name Registration BIFs.</tcaption>
+ <tcaption>Name Registration BIFs</tcaption>
</table>
</section>
@@ -79,22 +87,25 @@ spawn(Module, Name, Args) -> pid()
<marker id="term"></marker>
<title>Process Termination</title>
<p>When a process terminates, it always terminates with an
- <em>exit reason</em>. The reason may be any term.</p>
+ <em>exit reason</em>. The reason can be any term.</p>
<p>A process is said to terminate <em>normally</em>, if the exit
reason is the atom <c>normal</c>. A process with no more code to
execute terminates normally.</p>
- <p>A process terminates with exit reason <c>{Reason,Stack}</c>
+ <p>A process terminates with an exit reason <c>{Reason,Stack}</c>
when a run-time error occurs. See
- <seealso marker="errors#exit_reasons">Error and Error Handling</seealso>.</p>
- <p>A process can terminate itself by calling one of the BIFs
- <c>exit(Reason)</c>,
- <c>erlang:error(Reason)</c>, <c>erlang:error(Reason, Args)</c>,
- <c>erlang:fault(Reason)</c> or <c>erlang:fault(Reason, Args)</c>.
- The process then terminates with reason <c>Reason</c> for
- <c>exit/1</c> or <c>{Reason,Stack} for the others</c>.</p>
- <p>A process may also be terminated if it receives an exit signal
+ <seealso marker="errors#exit_reasons">Exit Reasons</seealso>.</p>
+ <p>A process can terminate itself by calling one of the
+ following BIFs:</p>
+ <list type="bulleted">
+ <item><c>exit(Reason)</c></item>
+ <item><c>erlang:error(Reason)</c></item>
+ <item><c>erlang:error(Reason, Args)</c></item>
+ </list>
+ <p>The process then terminates with reason <c>Reason</c> for
+ <c>exit/1</c> or <c>{Reason,Stack}</c> for the others.</p>
+ <p>A process can also be terminated if it receives an exit signal
with another exit reason than <c>normal</c>, see
- <seealso marker="#errors">Error Handling</seealso> below.</p>
+ <seealso marker="#errors">Error Handling</seealso>.</p>
</section>
<section>
@@ -113,35 +124,39 @@ spawn(Module, Name, Args) -> pid()
<title>Links</title>
<p>Two processes can be <em>linked</em> to each other. A link
between two processes <c>Pid1</c> and <c>Pid2</c> is created
- by <c>Pid1</c> calling the BIF <c>link(Pid2)</c> (or vice versa).
+ by <c>Pid1</c> calling the BIF <c>link(Pid2)</c> (or conversely).
There also exist a number of <c>spawn_link</c> BIFs, which spawn
and link to a process in one operation.</p>
<p>Links are bidirectional and there can only be one link between
two processes. Repeated calls to <c>link(Pid)</c> have no effect.</p>
<p>A link can be removed by calling the BIF <c>unlink(Pid)</c>.</p>
<p>Links are used to monitor the behaviour of other processes, see
- <seealso marker="#errors">Error Handling</seealso> below.</p>
+ <seealso marker="#errors">Error Handling</seealso>.</p>
</section>
<section>
<marker id="errors"></marker>
<title>Error Handling</title>
<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
+ processes. Terminating processes emit exit signals to all
+ linked processes, which can 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
+ processes, for example, restarting them if they terminate
abnormally.</p>
- <p>Refer to OTP Design Principles for more information about
- OTP supervision trees, which uses this feature.</p>
+ <p>See <seealso marker=
+ "doc/design_principles:des_princ#otp design principles">
+ OTP Design Principles</seealso> for more information about
+ OTP supervision trees, which use this feature.</p>
<section>
<title>Emitting Exit Signals</title>
- <p>When a process terminates, it will terminate with an <em>exit reason</em> as explained in <seealso marker="#term">Process Termination</seealso> above. This exit reason is emitted in
+ <p>When a process terminates, it terminates with an
+ <em>exit reason</em> as explained in <seealso marker="#term">
+ Process Termination</seealso>. This exit reason is emitted in
an <em>exit signal</em> to all linked processes.</p>
<p>A process can also call the function <c>exit(Pid,Reason)</c>.
- This will result in an exit signal with exit reason
+ This results in an exit signal with exit reason
<c>Reason</c> being emitted to <c>Pid</c>, but does not affect
the calling process.</p>
</section>
@@ -156,14 +171,14 @@ spawn(Module, Name, Args) -> pid()
<p>A process can be set to trap exit signals by calling:</p>
<pre>
process_flag(trap_exit, true)</pre>
- <p>When a process is trapping exits, it will not terminate when
+ <p>When a process is trapping exits, it does not terminate when
an exit signal is received. Instead, the signal is transformed
- into a message <c>{'EXIT',FromPid,Reason}</c> which is put into
- the mailbox of the process just like a regular message.</p>
+ into a message <c>{'EXIT',FromPid,Reason}</c>, which is put into
+ the mailbox of the process, just like a regular message.</p>
<p>An exception to the above is if the exit reason is <c>kill</c>,
- that is if <c>exit(Pid,kill)</c> has been called. This will
- unconditionally terminate the process, regardless of if it is
- trapping exit signals or not.</p>
+ that is if <c>exit(Pid,kill)</c> has been called. This
+ unconditionally terminates the process, regardless of if it is
+ trapping exit signals.</p>
</section>
</section>
@@ -180,12 +195,12 @@ process_flag(trap_exit, true)</pre>
<p>If <c>Pid2</c> does not exist, the 'DOWN' message is sent
immediately with <c>Reason</c> set to <c>noproc</c>.</p>
<p>Monitors are unidirectional. Repeated calls to
- <c>erlang:monitor(process, Pid)</c> will create several,
- independent monitors and each one will send a 'DOWN' message when
+ <c>erlang:monitor(process, Pid)</c> creates several
+ independent monitors, and each one sends a 'DOWN' message when
<c>Pid</c> terminates.</p>
<p>A monitor can be removed by calling
<c>erlang:demonitor(Ref)</c>.</p>
- <p>It is possible to create monitors for processes with registered
+ <p>Monitors can be created for processes with registered
names, also at other nodes.</p>
</section>