diff options
Diffstat (limited to 'lib/kernel/doc')
33 files changed, 6343 insertions, 6022 deletions
diff --git a/lib/kernel/doc/src/app.xml b/lib/kernel/doc/src/app.xml index 68c042b2ae..5e0da409a3 100644 --- a/lib/kernel/doc/src/app.xml +++ b/lib/kernel/doc/src/app.xml @@ -42,12 +42,12 @@ </description> <section> - <title>FILE SYNTAX</title> - <p>The application resource file should be called - <c>Application.app</c> where <c>Application</c> is the name of - the application. The file should be located in the <c>ebin</c> - directory for the application.</p> - <p>It must contain one single Erlang term, which is called an + <title>File Syntax</title> + <p>The application resource file is to be called + <c>Application.app</c>, where <c>Application</c> is the + application name. The file is to be located in directory <c>ebin</c> + for the application.</p> + <p>The file must contain a single Erlang term, which is called an <em>application specification</em>:</p> <code type="none"> {application, Application, @@ -80,19 +80,26 @@ Env [{Par,Val}] [] Start {Module,StartArgs} [] Phases [{Phase,PhaseArgs}] undefined RTDeps [ApplicationVersion] [] - Module = Name = App = Par = Phase = atom() - Val = StartArgs = PhaseArgs = term() - ApplicationVersion = string()</code> - <p><c>Application</c> is the name of the application.</p> + +Module = Name = App = Par = Phase = atom() +Val = StartArgs = PhaseArgs = term() +ApplicationVersion = string()</code> + <taglist> + <tag><c>Application</c></tag> + <item>Application name.</item> + </taglist> <p>For the application controller, all keys are optional. The respective default values are used for any omitted keys.</p> <p>The functions in <c>systools</c> require more information. If - they are used, the following keys are mandatory: - <c>description</c>, <c>vsn</c>, <c>modules</c>, <c>registered</c> - and <c>applications</c>. The other keys are ignored by - <c>systools</c>.</p> - <warning><p>The <c>RTDeps</c> type was introduced in OTP 17.0 and - might be subject to changes during the OTP 17 release.</p></warning> + they are used, the following keys are mandatory:</p> + <list type="bulleted"> + <item><c>description</c></item> + <item><c>vsn</c></item> + <item><c>modules</c></item> + <item><c>registered</c></item> + <item><c>applications</c></item> + </list> + <p>The other keys are ignored by <c>systools</c>.</p> <taglist> <tag><c>description</c></tag> <item> @@ -104,7 +111,7 @@ RTDeps [ApplicationVersion] [] </item> <tag><c>vsn</c></tag> <item> - <p>The version of the application.</p> + <p>Version of the application.</p> </item> <tag><c>modules</c></tag> <item> @@ -114,15 +121,14 @@ RTDeps [ApplicationVersion] [] </item> <tag><c>maxP</c></tag> <item> - <p><em>Deprecated - will be ignored</em> <br></br> - - The maximum number of processes allowed in the application.</p> + <p><em>Deprecated - is ignored</em></p> + <p>Maximum number of processes allowed in the application.</p> </item> <tag><c>maxT</c></tag> <item> - <p>The maximum time in milliseconds that the application is - allowed to run. After the specified time the application will - automatically terminate.</p> + <p>Maximum time, in milliseconds, that the application is + allowed to run. After the specified time, the application + terminates automatically.</p> </item> <tag><c>registered</c></tag> <item> @@ -132,20 +138,20 @@ RTDeps [ApplicationVersion] [] </item> <tag><c>included_applications</c></tag> <item> - <p>All applications which are included by this application. - When this application is started, all included application - will automatically be loaded, but not started, by - the application controller. It is assumed that the topmost + <p>All applications included by this application. + When this application is started, all included applications + are loaded automatically, but not started, by + the application controller. It is assumed that the top-most supervisor of the included application is started by a supervisor of this application.</p> </item> <tag><c>applications</c></tag> <item> - <p>All applications which must be started before this + <p>All applications that must be started before this application is allowed to be started. <c>systools</c> uses this list to generate correct start scripts. Defaults to - the empty list, but note that all applications have - dependencies to (at least) <c>kernel</c> and <c>stdlib</c>.</p> + the empty list, but notice that all applications have + dependencies to (at least) <c>Kernel</c> and <c>STDLIB</c>.</p> </item> <tag><c>env</c></tag> <item> @@ -153,78 +159,84 @@ RTDeps [ApplicationVersion] [] of a configuration parameter is retrieved by calling <c>application:get_env/1,2</c>. The values in the application resource file can be overridden by values in a configuration - file (see <c>config(4)</c>) or by command line flags (see - <c>erl(1)</c>).</p> + file (see <seealso marker="config"><c>config(4)</c></seealso>) + or by command-line flags (see + <seealso marker="erts:erl"><c>erts:erl(1)</c></seealso>).</p> </item> <tag><c>mod</c></tag> <item> - <p>Specifies the application callback module and a start - argument, see <c>application(3)</c>.</p> - <p>The <c>mod</c> key is necessary for an application - implemented as a supervision tree, or the application - controller will not know how to start it. The <c>mod</c> key + <p>Specifies the application callback module and a start argument, see + <seealso marker="application"><c>application(3)</c></seealso>.</p> + <p>Key <c>mod</c> is necessary for an application + implemented as a supervision tree, otherwise the application + controller does not know how to start it. <c>mod</c> can be omitted for applications without processes, typically - code libraries such as the application STDLIB.</p> + code libraries, for example, <c>STDLIB</c>.</p> </item> <tag><c>start_phases</c></tag> <item> <p>A list of start phases and corresponding start arguments for the application. If this key is present, the application - master will - in addition to the usual call to - <c>Module:start/2</c> - also call + master, in addition to the usual call to + <c>Module:start/2</c>, also calls <c>Module:start_phase(Phase,Type,PhaseArgs)</c> for each - start phase defined by the <c>start_phases</c> key, and only - after this extended start procedure will - <c>application:start(Application)</c> return.</p> - <p>Start phases may be used to synchronize startup of an + start phase defined by key <c>start_phases</c>. Only + after this extended start procedure, + <c>application:start(Application)</c> returns.</p> + <p>Start phases can be used to synchronize startup of an application and its included applications. In this case, - the <c>mod</c> key must be specified as:</p> + key <c>mod</c> must be specified as follows:</p> <code type="none"> {mod, {application_starter,[Module,StartArgs]}}</code> - <p>The application master will then call <c>Module:start/2</c> + <p>The application master then calls <c>Module:start/2</c> for the primary application, followed by calls to <c>Module:start_phase/3</c> for each start phase (as defined - for the primary application) both for the primary application - and for each of its included application, for which the start + for the primary application), both for the primary application + and for each of its included applications, for which the start phase is defined.</p> <p>This implies that for an included application, the set of start phases must be a subset of the set of phases defined - for the primary application. Refer to <em>OTP Design Principles</em> for more information.</p> + for the primary application. For more information, see + <seealso marker="doc/design_principles:applications">OTP Design Principles</seealso>. + </p> </item> - <tag><marker id="runtime_dependencies"></marker><c>runtime_dependencies</c></tag> - <item><p>A list of application versions that the application - depends on. An example of such an application version is - <c>"kernel-3.0"</c>. Application versions specified as runtime - dependencies are minimum requirements. That is, a larger - application version than the one specified in the - dependency satisfies the requirement. For information on - how to compare application versions see - <seealso marker="doc/system_principles:versions">the - documentation of versions in the system principles - guide</seealso>. Note that the application version - specifies a source code version. An additional indirect - requirement is that installed binary application of - the specified version has been built so that it is - compatible with the rest of the system.</p> - <p>Some dependencies might only be required in specific runtime - scenarios. In the case such optional dependencies exist, these are - specified and documented in the corresponding "App" documentation - of the specific application.</p> - <warning><p>The <c>runtime_dependencies</c> key was introduced in - OTP 17.0. The type of its value might be subject to changes during - the OTP 17 release.</p></warning> - <warning><p>All runtime dependencies specified in OTP applications - during the OTP 17 release may not be completely correct. This - is actively being worked on. Declared runtime dependencies in OTP - applications are expected to be correct in OTP 18.</p></warning> + <tag> + <marker id="runtime_dependencies"></marker> + <c>runtime_dependencies</c></tag> + <item> + <p>A list of application versions that the application + depends on. An example of such an application version is + <c>"kernel-3.0"</c>. Application versions specified as runtime + dependencies are minimum requirements. That is, a larger + application version than the one specified in the + dependency satisfies the requirement. For information about + how to compare application versions, see section + <seealso marker="doc/system_principles:versions">Versions</seealso> + in the System Principles User's Guide.</p> + <p>Notice that the application version + specifies a source code version. One more, indirect, + requirement is that the installed binary application of + the specified version is built so that it is + compatible with the rest of the system.</p> + <p>Some dependencies can only be required in specific runtime + scenarios. When such optional dependencies exist, these are + specified and documented in the corresponding "App" documentation + of the specific application.</p> + <warning><p>The <c>runtime_dependencies</c> key was introduced in + OTP 17.0. The type of its value might be subject to changes during + the OTP 17 release.</p></warning> + <warning><p>All runtime dependencies specified in OTP applications + during the OTP 17 release may not be completely correct. This + is actively being worked on. Declared runtime dependencies in OTP + applications are expected to be correct in OTP 18.</p></warning> </item> </taglist> </section> <section> - <title>SEE ALSO</title> - <p><seealso marker="application">application(3)</seealso>, - systools(3)</p> + <title>See Also</title> + <p><seealso marker="application"><c>application(3)</c></seealso>, + <seealso marker="sasl:systools"><c>sasl:systools(3)</c></seealso></p> </section> </fileref> diff --git a/lib/kernel/doc/src/application.xml b/lib/kernel/doc/src/application.xml index 3e3e6cdfa9..3928078932 100644 --- a/lib/kernel/doc/src/application.xml +++ b/lib/kernel/doc/src/application.xml @@ -33,23 +33,25 @@ <description> <p>In OTP, <em>application</em> denotes a component implementing some specific functionality, that can be started and stopped as a - unit, and which can be re-used in other systems as well. This - module interfaces the <em>application controller</em>, a process - started at every Erlang runtime system, and contains functions - for controlling applications (for example starting and stopping + unit, and that can be reused in other systems. This + module interacts with <em>application controller</em>, a process + started at every Erlang runtime system. This module contains functions + for controlling applications (for example, starting and stopping applications), and functions to access information about - applications (for example configuration parameters).</p> - <p>An application is defined by an <em>application specification</em>. The specification is normally located in an - <em>application resource file</em> called <c>Application.app</c>, - where <c>Application</c> is the name of the application. Refer to - <seealso marker="app">app(4)</seealso> for more information about - the application specification.</p> + applications (for example, configuration parameters).</p> + <p>An application is defined by an <em>application specification</em>. + The specification is normally located in an + <em>application resource file</em> named <c>Application.app</c>, + where <c>Application</c> is the application name. For details + about the application specification, see + <seealso marker="app"><c>app(4)</c></seealso>.</p> <p>This module can also be viewed as a behaviour for an application implemented according to the OTP design principles as a supervision tree. The definition of how to start and stop - the tree should be located in an <em>application callback module</em> exporting a pre-defined set of functions.</p> - <p>Refer to <seealso marker="doc/design_principles:des_princ">OTP Design Principles</seealso> for more information about - applications and behaviours.</p> + the tree is to be located in an <em>application callback module</em>, + exporting a predefined set of functions.</p> + <p>For details about applications and behaviours, see + <seealso marker="doc/design_principles:des_princ">OTP Design Principles</seealso>.</p> </description> <datatypes> <datatype> @@ -59,7 +61,6 @@ <name name="restart_type"/> </datatype> <datatype> - <!-- Parameterized opaque types are NYI: --> <name>tuple_of(T)</name> <desc><p><marker id="type-tuple_of"/> A tuple where the elements are of type <c>T</c>.</p></desc> @@ -67,9 +68,37 @@ </datatypes> <funcs> <func> + <name name="ensure_all_started" arity="1"/> + <name name="ensure_all_started" arity="2"/> + <fsummary>Load and start an application and its dependencies, recursively.</fsummary> + <desc> + <p>Equivalent to calling + <seealso marker="#start/1"><c>start/1,2</c></seealso> + repeatedly on all dependencies that are not yet started for an application.</p> + <p>Returns <c>{ok, AppNames}</c> for a successful start or for an already started + application (which is, however, omitted from the <c>AppNames</c> list).</p> + <p>The function reports <c>{error, {AppName,Reason}}</c> for errors, where + <c>Reason</c> is any possible reason returned by + <seealso marker="#start/1"><c>start/1,2</c></seealso> + when starting a specific dependency.</p> + <p>If an error occurs, the applications started by the function are stopped + to bring the set of running applications back to its initial state.</p> + </desc> + </func> + <func> + <name name="ensure_started" arity="1"/> + <name name="ensure_started" arity="2"/> + <fsummary>Load and start an application.</fsummary> + <desc> + <p>Equivalent to + <seealso marker="#start/1"><c>start/1,2</c></seealso> + except it returns <c>ok</c> for already started applications.</p> + </desc> + </func> + <func> <name name="get_all_env" arity="0"/> <name name="get_all_env" arity="1"/> - <fsummary>Get the configuration parameters for an application</fsummary> + <fsummary>Get the configuration parameters for an application.</fsummary> <desc> <p>Returns the configuration parameters and their values for <c><anno>Application</anno></c>. If the argument is omitted, it defaults to @@ -82,7 +111,7 @@ <func> <name name="get_all_key" arity="0"/> <name name="get_all_key" arity="1"/> - <fsummary>Get the application specification keys</fsummary> + <fsummary>Get the application specification keys.</fsummary> <desc> <p>Returns the application specification keys and their values for <c><anno>Application</anno></c>. If the argument is omitted, it @@ -96,7 +125,7 @@ <func> <name name="get_application" arity="0"/> <name name="get_application" arity="1"/> - <fsummary>Get the name of an application containing a certain process or module</fsummary> + <fsummary>Get the name of an application containing a certain process or module.</fsummary> <desc> <p>Returns the name of the application to which the process <c><anno>Pid</anno></c> or the module <c><anno>Module</anno></c> belongs. Providing no @@ -110,222 +139,212 @@ <func> <name name="get_env" arity="1"/> <name name="get_env" arity="2"/> - <fsummary>Get the value of a configuration parameter</fsummary> + <fsummary>Get the value of a configuration parameter.</fsummary> <desc> - <p>Returns the value of the configuration parameter <c><anno>Par</anno></c> + <p>Returns the value of configuration parameter <c><anno>Par</anno></c> for <c><anno>Application</anno></c>. If the application argument is omitted, it defaults to the application of the calling process.</p> - <p>If the specified application is not loaded, or - the configuration parameter does not exist, or if the process - executing the call does not belong to any application, - the function returns <c>undefined</c>.</p> + <p>Returns <c>undefined</c> if any of the following applies:</p> + <list type="bulleted"> + <item>The specified application is not loaded.</item> + <item>The configuration parameter does not exist.</item> + <item>The process executing the call does not belong to any application.</item> + </list> </desc> </func> <func> <name name="get_env" arity="3"/> - <fsummary>Get the value of a configuration parameter using a default</fsummary> + <fsummary>Get the value of a configuration parameter using a default.</fsummary> <desc> - <p>Works like <seealso marker="#get_env/2">get_env/2</seealso> but returns - <c><anno>Def</anno></c> value when configuration parameter + <p>Works like <seealso marker="#get_env/2"><c>get_env/2</c></seealso> but returns + value <c><anno>Def</anno></c> when configuration parameter <c><anno>Par</anno></c> does not exist.</p> </desc> </func> <func> <name name="get_key" arity="1"/> <name name="get_key" arity="2"/> - <fsummary>Get the value of an application specification key</fsummary> + <fsummary>Get the value of an application specification key.</fsummary> <desc> <p>Returns the value of the application specification key <c><anno>Key</anno></c> for <c><anno>Application</anno></c>. If the application argument is omitted, it defaults to the application of the calling process.</p> - <p>If the specified application is not loaded, or - the specification key does not exist, or if the process - executing the call does not belong to any application, - the function returns <c>undefined</c>.</p> + <p>Returns <c>undefined</c> if any of the following applies:</p> + <list type="bulleted"> + <item>The specified application is not loaded.</item> + <item>The specification key does not exist.</item> + <item>The process executing the call does not belong to any application.</item> + </list> + </desc> </func> <func> <name name="load" arity="1"/> <name name="load" arity="2"/> - <fsummary>Load an application</fsummary> + <fsummary>Load an application.</fsummary> <type name="application_spec"/> <type name="application_opt"/> <desc> <p>Loads the application specification for an application into - the application controller. It will also load the application - specifications for any included applications. Note that - the function does not load the actual Erlang object code.</p> - <p>The application can be given by its name <c><anno>Application</anno></c>. - In this case the application controller will search the code + the application controller. It also loads the application + specifications for any included applications. Notice that + the function does not load the Erlang object code.</p> + <p>The application can be specified by its name <c><anno>Application</anno></c>. + In this case, the application controller searches the code path for the application resource file <c><anno>Application</anno>.app</c> - and load the specification it contains.</p> - <p>The application specification can also be given directly as a - tuple <c><anno>AppSpec</anno></c>. This tuple should have the format and - contents as described in <c>app(4)</c>.</p> + and loads the specification it contains.</p> + <p>The application specification can also be specified directly as a + tuple <c><anno>AppSpec</anno></c>, having the format and + contents as described in + <seealso marker="app"><c>app(4)</c></seealso>.</p> <p>If <c><anno>Distributed</anno> == {<anno>Application</anno>,[<anno>Time</anno>,]<anno>Nodes</anno>}</c>, - the application will be distributed. The argument overrides - the value for the application in the Kernel configuration + the application becomes distributed. The argument overrides + the value for the application in the <c>Kernel</c> configuration parameter <c>distributed</c>. <c><anno>Application</anno></c> must be - the name of the application (same as in the first argument). - If a node crashes and <c><anno>Time</anno></c> has been specified, then - the application controller will wait for <c><anno>Time</anno></c> + the application name (same as in the first argument). + If a node crashes and <c><anno>Time</anno></c> is specified, + the application controller waits for <c><anno>Time</anno></c> milliseconds before attempting to restart the application on - another node. If <c><anno>Time</anno></c> is not specified, it will - default to 0 and the application will be restarted + another node. If <c><anno>Time</anno></c> is not specified, it + defaults to <c>0</c> and the application is restarted immediately.</p> <p><c><anno>Nodes</anno></c> is a list of node names where the application - may run, in priority from left to right. Node names can be + can run, in priority from left to right. Node names can be grouped using tuples to indicate that they have the same - priority. Example:</p> + priority.</p> + <p><em>Example:</em></p> <code type="none"> Nodes = [cp1@cave, {cp2@cave, cp3@cave}]</code> - <p>This means that the application should preferably be started + <p>This means that the application is preferably to be started at <c>cp1@cave</c>. If <c>cp1@cave</c> is down, - the application should be started at either <c>cp2@cave</c> + the application is to be started at <c>cp2@cave</c> or <c>cp3@cave</c>.</p> <p>If <c>Distributed == default</c>, the value for - the application in the Kernel configuration parameter - <c>distributed</c> will be used.</p> + the application in the <c>Kernel</c> configuration parameter + <c>distributed</c> is used.</p> </desc> </func> <func> <name name="loaded_applications" arity="0"/> - <fsummary>Get the currently loaded applications</fsummary> + <fsummary>Get the currently loaded applications.</fsummary> <desc> - <p>Returns a list with information about the applications which - have been loaded using <c>load/1,2</c>, also included - applications. <c><anno>Application</anno></c> is the application name. - <c><anno>Description</anno></c> and <c><anno>Vsn</anno></c> are the values of its - <c>description</c> and <c>vsn</c> application specification + <p>Returns a list with information about the applications, and included + applications, which are loaded using <c>load/1,2</c>. + <c><anno>Application</anno></c> is the application name. + <c><anno>Description</anno></c> and <c><anno>Vsn</anno></c> are the values + of their <c>description</c> and <c>vsn</c> application specification keys, respectively.</p> </desc> </func> <func> <name name="permit" arity="2"/> - <fsummary>Change an application's permission to run on a node.</fsummary> + <fsummary>Change the permission for an application to run at a node.</fsummary> <desc> <p>Changes the permission for <c><anno>Application</anno></c> to run at - the current node. The application must have been loaded using + the current node. The application must be loaded using <c>load/1,2</c> for the function to have effect.</p> <p>If the permission of a loaded, but not started, application - is set to <c>false</c>, <c>start</c> will return <c>ok</c> but - the application will not be started until the permission is + is set to <c>false</c>, <c>start</c> returns <c>ok</c> but + the application is not started until the permission is set to <c>true</c>.</p> <p>If the permission of a running application is set to - <c>false</c>, the application will be stopped. If - the permission later is set to <c>true</c>, it will be + <c>false</c>, the application is stopped. If + the permission later is set to <c>true</c>, it is restarted.</p> <p>If the application is distributed, setting the permission to <c>false</c> means that the application will be started at, or moved to, another node according to how its distribution is - configured (see <c>load/2</c> above).</p> + configured + (see <seealso marker="#load/2"><c>load/2</c></seealso>).</p> <p>The function does not return until the application is - started, stopped or successfully moved to another node. - However, in some cases where permission is set to <c>true</c> - the function may return <c>ok</c> even though the application - itself has not started. This is true when an application - cannot start because it has dependencies to other - applications which have not yet been started. When they have - been started, <c>Application</c> will be started as well.</p> + started, stopped, or successfully moved to another node. + However, in some cases where permission is set to <c>true</c>, + the function returns <c>ok</c> even though the application + is not started. This is true when an application + cannot start because of dependencies to other + applications that are not yet started. When they are + started, <c>Application</c> is started as well.</p> <p>By default, all applications are loaded with permission - <c>true</c> on all nodes. The permission is configurable by - using the Kernel configuration parameter <c>permissions</c>.</p> + <c>true</c> on all nodes. The permission can be configured + using the <c>Kernel</c> configuration parameter <c>permissions</c>.</p> </desc> </func> <func> <name name="set_env" arity="3"/> <name name="set_env" arity="4"/> - <fsummary>Set the value of a configuration parameter</fsummary> + <fsummary>Set the value of a configuration parameter.</fsummary> <desc> - <p>Sets the value of the configuration parameter <c><anno>Par</anno></c> for + <p>Sets the value of configuration parameter <c><anno>Par</anno></c> for <c><anno>Application</anno></c>.</p> - <p><c>set_env/4</c> uses the standard <c>gen_server</c> timeout - value (5000 ms). The <c>timeout</c> option can be provided - if another timeout value is useful, for example, in situations + <p><c>set_env/4</c> uses the standard <c>gen_server</c> time-out + value (5000 ms). Option <c>timeout</c> can be specified + if another time-out value is useful, for example, in situations where the application controller is heavily loaded.</p> <p>If <c>set_env/4</c> is called before the application is loaded, - the application environment values specified in the <c>Application.app</c> - file will override the ones previously set. This is also true for application + the application environment values specified in file <c>Application.app</c> + override the ones previously set. This is also true for application reloads.</p> - <p>The <c>persistent</c> option can be set to <c>true</c> - when there is a need to guarantee parameters set with <c>set_env/4</c> - will not be overridden by the ones defined in the application resource - file on load. This means persistent values will stick after the application + <p>Option <c>persistent</c> can be set to <c>true</c> + to guarantee that parameters set with <c>set_env/4</c> + are not overridden by those defined in the application resource + file on load. This means that persistent values will stick after the application is loaded and also on application reload.</p> <warning> - <p>Use this function only if you know what you are doing, - that is, on your own applications. It is very application - and configuration parameter dependent when and how often - the value is read by the application, and careless use - of this function may put the application in a - weird, inconsistent, and malfunctioning state. </p> + <p>Use this function only if you know what you are doing, + that is, on your own applications. It is very + application-dependent and + configuration parameter-dependent when and how often + the value is read by the application. Careless use + of this function can put the application in a + weird, inconsistent, and malfunctioning state.</p> </warning> </desc> </func> <func> - <name name="ensure_started" arity="1"/> - <name name="ensure_started" arity="2"/> - <fsummary>Load and start an application</fsummary> - <desc> - <p>Equivalent to <seealso marker="#start/2"><c>application:start/1,2</c></seealso> except - it returns <c>ok</c> for already started applications.</p> - </desc> - </func> - <func> - <name name="ensure_all_started" arity="1"/> - <name name="ensure_all_started" arity="2"/> - <fsummary>Load and start an application and its dependencies, recursively</fsummary> - <desc> - <p>Equivalent to calling <seealso marker="#start/2"><c>application:start/1,2</c></seealso> - repeatedly on all dependencies that have not yet been started for an application. - The function returns <c>{ok, AppNames}</c> for a successful start or for an already started - application (which are however omitted from the <c>AppNames</c> list), and reports - <c>{error, {AppName,Reason}}</c> for errors, where <c>Reason</c> is any possible reason - returned by <seealso marker="#start/2"><c>application:start/1,2</c></seealso> when starting a - specific dependency. In case of an error, the applications that were started by the - function are stopped to bring the set of running applications back to its initial state.</p> - </desc> - </func> - <func> <name name="start" arity="1"/> <name name="start" arity="2"/> - <fsummary>Load and start an application</fsummary> - <desc> + <fsummary>Load and start an application.</fsummary> + <desc> <p>Starts <c><anno>Application</anno></c>. If it is not loaded, - the application controller will first load it using - <c>load/1</c>. It will make sure any included applications - are loaded, but will not start them. That is assumed to be + the application controller first loads it using + <c>load/1</c>. It ensures that any included applications + are loaded, but does not start them. That is assumed to be taken care of in the code for <c><anno>Application</anno></c>.</p> <p>The application controller checks the value of the application specification key <c>applications</c>, to - ensure that all applications that should be started before - this application are running. If not, + ensure that all applications needed to be started before + this application are running. Otherwise, <c>{error,{not_started,App}}</c> is returned, where <c>App</c> is the name of the missing application.</p> - <p>The application controller then creates an <em>application master</em> for the application. The application master is + <p>The application controller then creates an <em>application master</em> + for the application. The application master is the group leader of all the processes in the application. The application master starts the application by calling the application callback function <c>Module:start/2</c> as defined by the application specification key <c>mod</c>.</p> - <p>The <c><anno>Type</anno></c> argument specifies the type of + <p>Argument <c><anno>Type</anno></c> specifies the type of the application. If omitted, it defaults to <c>temporary</c>.</p> <list type="bulleted"> <item>If a permanent application terminates, all other applications and the entire Erlang node are also terminated.</item> - <item>If a transient application terminates with <c>Reason == normal</c>, this is reported but no other applications are - terminated. If a transient application terminates - abnormally, all other applications and the entire Erlang - node are also terminated.</item> + <item> + <list type="bulleted"> + <item>If a transient application terminates with <c>Reason == normal</c>, + this is reported but no other applications are terminated.</item> + <item>If a transient application terminates abnormally, all other + applications and the entire Erlang node are also terminated.</item> + </list> + </item> <item>If a temporary application terminates, this is reported but no other applications are terminated.</item> </list> - <p>Note that it is always possible to stop an application + <p>Notice that an application can always be stopped explicitly by calling <c>stop/1</c>. Regardless of the type of - the application, no other applications will be affected.</p> - <p>Note also that the transient type is of little practical use, - since when a supervision tree terminates, the reason is set to + the application, no other applications are affected.</p> + <p>Notice also that the transient type is of little practical use, + because when a supervision tree terminates, the reason is set to <c>shutdown</c>, not <c>normal</c>.</p> </desc> </func> @@ -334,13 +353,13 @@ Nodes = [cp1@cave, {cp2@cave, cp3@cave}]</code> <fsummary>Get the start type of an ongoing application startup.</fsummary> <desc> <p>This function is intended to be called by a process belonging - to an application, when the application is being started, to - determine the start type which is either <c><anno>StartType</anno></c> or + to an application, when the application is started, to + determine the start type, which is <c><anno>StartType</anno></c> or <c>local</c>.</p> - <p>See <seealso marker="#start_type"><c>Module:start/2</c></seealso> for a description of - <c><anno>StartType</anno></c>.</p> - <p><c>local</c> is returned if only parts of the application is - being restarted (by a supervisor), or if the function is + <p>For a description of <c><anno>StartType</anno></c>, see + <seealso marker="#start_type"><c>Module:start/2</c></seealso>.</p> + <p><c>local</c> is returned if only parts of the application are + restarted (by a supervisor), or if the function is called outside a startup.</p> <p>If the process executing the call does not belong to any application, the function returns <c>undefined</c>.</p> @@ -348,103 +367,106 @@ Nodes = [cp1@cave, {cp2@cave, cp3@cave}]</code> </func> <func> <name name="stop" arity="1"/> - <fsummary>Stop an application</fsummary> + <fsummary>Stop an application.</fsummary> <desc> <p>Stops <c><anno>Application</anno></c>. The application master calls <c>Module:prep_stop/1</c>, if such a function is defined, and - then tells the top supervisor of the application to shutdown - (see <c>supervisor(3)</c>). This means that the entire + then tells the top supervisor of the application to shut down + (see <seealso marker="stdlib:supervisor"><c>supervisor(3)</c></seealso>). + This means that the entire supervision tree, including included applications, is terminated in reversed start order. After the shutdown, the application master calls <c>Module:stop/1</c>. <c>Module</c> is the callback module as defined by the application specification key <c>mod</c>.</p> - <p>Last, the application master itself terminates. Note that all - processes with the application master as group leader, i.e. + <p>Last, the application master terminates. Notice that all + processes with the application master as group leader, that is, processes spawned from a process belonging to the application, - thus are terminated as well.</p> + are also terminated.</p> <p>When stopped, the application is still loaded.</p> - <p>In order to stop a distributed application, <c>stop/1</c> - has to be called on all nodes where it can execute (that is, + <p>To stop a distributed application, <c>stop/1</c> + must be called on all nodes where it can execute (that is, on all nodes where it has been started). The call to <c>stop/1</c> on the node where the application currently - executes will stop its execution. The application will not be - moved between nodes due to <c>stop/1</c> being called on + executes stops its execution. The application is not + moved between nodes, as <c>stop/1</c> is called on the node where the application currently executes before <c>stop/1</c> is called on the other nodes.</p> </desc> </func> <func> <name name="takeover" arity="2"/> - <fsummary>Take over a distributed application</fsummary> + <fsummary>Take over a distributed application.</fsummary> <desc> - <p>Performs a takeover of the distributed application + <p>Takes over the distributed application <c><anno>Application</anno></c>, which executes at another node <c>Node</c>. At the current node, the application is restarted by calling <c>Module:start({takeover,Node},StartArgs)</c>. <c>Module</c> and <c>StartArgs</c> are retrieved from the loaded application specification. The application at the other node is not - stopped until the startup is completed, i.e. when + stopped until the startup is completed, that is, when <c>Module:start/2</c> and any calls to <c>Module:start_phase/3</c> have returned.</p> - <p>Thus two instances of the application will run simultaneously - during the takeover, which makes it possible to transfer data - from the old to the new instance. If this is not acceptable - behavior, parts of the old instance may be shut down when - the new instance is started. Note that the application may - not be stopped entirely however, at least the top supervisor + <p>Thus, two instances of the application run simultaneously + during the takeover, so that data can be transferred + from the old to the new instance. If this is not an acceptable + behavior, parts of the old instance can be shut down when + the new instance is started. However, the application cannot + be stopped entirely, at least the top supervisor must remain alive.</p> - <p>See <c>start/1,2</c> for a description of <c>Type</c>.</p> + <p>For a description of <c>Type</c>, see + <seealso marker="#start/1"><c>start/1,2</c></seealso>.</p> </desc> </func> <func> <name name="unload" arity="1"/> - <fsummary>Unload an application</fsummary> + <fsummary>Unload an application.</fsummary> <desc> <p>Unloads the application specification for <c><anno>Application</anno></c> - from the application controller. It will also unload + from the application controller. It also unloads the application specifications for any included applications. - Note that the function does not purge the actual Erlang + Notice that the function does not purge the Erlang object code.</p> </desc> </func> <func> <name name="unset_env" arity="2"/> <name name="unset_env" arity="3"/> - <fsummary>Unset the value of a configuration parameter</fsummary> + <fsummary>Unset the value of a configuration parameter.</fsummary> <desc> <p>Removes the configuration parameter <c><anno>Par</anno></c> and its value for <c><anno>Application</anno></c>.</p> <p><c>unset_env/2</c> uses the standard <c>gen_server</c> - timeout value (5000 ms). The <c>timeout</c> option can be - provided if another timeout value is useful, for example, in + time-out value (5000 ms). Option <c>timeout</c> can be + specified if another time-out value is useful, for example, in situations where the application controller is heavily loaded.</p> <p><c>unset_env/3</c> also allows the persistent option to be passed - (see <c>set_env/4</c> above).</p> - <warning> - <p>Use this function only if you know what you are doing, - that is, on your own applications. It is very application - and configuration parameter dependent when and how often - the value is read by the application, and careless use - of this function may put the application in a - weird, inconsistent, and malfunctioning state. </p> + (see <seealso marker="#set_env/4"><c>set_env/4</c></seealso>).</p> + <warning> + <p>Use this function only if you know what you are doing, + that is, on your own applications. It is very + application-dependent and configuration + parameter-dependent when and how often + the value is read by the application. Careless use + of this function can put the application in a + weird, inconsistent, and malfunctioning state.</p> </warning> </desc> </func> <func> <name name="which_applications" arity="0"/> <name name="which_applications" arity="1"/> - <fsummary>Get the currently running applications</fsummary> + <fsummary>Get the currently running applications.</fsummary> <desc> - <p>Returns a list with information about the applications which + <p>Returns a list with information about the applications that are currently running. <c><anno>Application</anno></c> is the application - name. <c><anno>Description</anno></c> and <c><anno>Vsn</anno></c> are the values of its - <c>description</c> and <c>vsn</c> application specification + name. <c><anno>Description</anno></c> and <c><anno>Vsn</anno></c> are the + values of their <c>description</c> and <c>vsn</c> application specification keys, respectively.</p> <p><c>which_applications/0</c> uses the standard - <c>gen_server</c> timeout value (5000 ms). A <c><anno>Timeout</anno></c> - argument can be provided if another timeout value is useful, + <c>gen_server</c> time-out value (5000 ms). A <c><anno>Timeout</anno></c> + argument can be specified if another time-out value is useful, for example, in situations where the application controller is heavily loaded.</p> </desc> @@ -452,81 +474,81 @@ Nodes = [cp1@cave, {cp2@cave, cp3@cave}]</code> </funcs> <section> - <title>CALLBACK MODULE</title> - <p>The following functions should be exported from an + <title>Callback Module</title> + <p>The following functions are to be exported from an <c>application</c> callback module.</p> </section> <funcs> <func> <name>Module:start(StartType, StartArgs) -> {ok, Pid} | {ok, Pid, State} | {error, Reason}</name> - <fsummary>Start an application</fsummary> + <fsummary>Start an application.</fsummary> <type> - <v>StartType = <seealso marker="#type-start_type">start_type()</seealso></v> + <v>StartType = <seealso marker="#type-start_type"><c>start_type()</c></seealso></v> <v>StartArgs = term()</v> <v>Pid = pid()</v> <v>State = term()</v> </type> <desc> <p>This function is called whenever an application is started - using <c>application:start/1,2</c>, and should start + using <c>start/1,2</c>, and is to start the processes of the application. If the application is structured according to the OTP design principles as a supervision tree, this means starting the top supervisor of the tree.</p> <p><marker id="start_type"/><c>StartType</c> defines the type of start:</p> <list type="bulleted"> - <item><c>normal</c> if it's a normal startup.</item> + <item><c>normal</c> if it is a normal startup.</item> <item><c>normal</c> also if the application is distributed and - started at the current node due to a failover from another + started at the current node because of a failover from another node, and the application specification key <c>start_phases == undefined</c>.</item> <item><c>{takeover,Node}</c> if the application is - distributed and started at the current node due to a + distributed and started at the current node because of a takeover from <c>Node</c>, either because - <c>application:takeover/2</c> has been called or because + <c>takeover/2</c> has been called or because the current node has higher priority than <c>Node</c>.</item> <item><c>{failover,Node}</c> if the application is - distributed and started at the current node due to a + distributed and started at the current node because of a failover from <c>Node</c>, and the application specification key <c>start_phases /= undefined</c>.</item> </list> <p><c>StartArgs</c> is the <c>StartArgs</c> argument defined by the application specification key <c>mod</c>.</p> - <p>The function should return <c>{ok,Pid}</c> or - <c>{ok,Pid,State}</c> where <c>Pid</c> is the pid of the top + <p>The function is to return <c>{ok,Pid}</c> or + <c>{ok,Pid,State}</c>, where <c>Pid</c> is the pid of the top supervisor and <c>State</c> is any term. If omitted, - <c>State</c> defaults to <c>[]</c>. If later the application - is stopped, <c>State</c> is passed to + <c>State</c> defaults to <c>[]</c>. If the application + is stopped later, <c>State</c> is passed to <c>Module:prep_stop/1</c>.</p> </desc> </func> <func> <name>Module:start_phase(Phase, StartType, PhaseArgs) -> ok | {error, Reason}</name> - <fsummary>Extended start of an application</fsummary> + <fsummary>Extended start of an application.</fsummary> <type> <v>Phase = atom()</v> - <v>StartType = <seealso marker="#type-start_type">start_type()</seealso></v> + <v>StartType = <seealso marker="#type-start_type"><c>start_type()</c></seealso></v> <v>PhaseArgs = term()</v> <v>Pid = pid()</v> <v>State = state()</v> </type> <desc> - <p>This function is used to start an application with included - applications, when there is a need for synchronization between + <p>Starts an application with included + applications, when synchronization is needed between processes in the different applications during startup.</p> - <p>The start phases is defined by the application specification + <p>The start phases are defined by the application specification key <c>start_phases == [{Phase,PhaseArgs}]</c>. For included applications, the set of phases must be a subset of the set of phases defined for the including application.</p> <p>The function is called for each start phase (as defined for the primary application) for the primary application and all included applications, for which the start phase is defined.</p> - <p>See <c>Module:start/2</c> for a description of - <c>StartType</c>.</p> + <p>For a description of <c>StartType</c>, see + <seealso marker="Module:start/2"><c>Module:start/2</c></seealso>.</p> </desc> </func> <func> <name>Module:prep_stop(State) -> NewState</name> - <fsummary>Prepare an application for termination</fsummary> + <fsummary>Prepare an application for termination.</fsummary> <type> <v>State = NewState = term()</v> </type> @@ -536,28 +558,26 @@ Nodes = [cp1@cave, {cp2@cave, cp3@cave}]</code> the application.</p> <p><c>State</c> is the state returned from <c>Module:start/2</c>, or <c>[]</c> if no state was returned. - <c>NewState</c> is any term and will be passed to + <c>NewState</c> is any term and is passed to <c>Module:stop/1</c>.</p> <p>The function is optional. If it is not defined, the processes - will be terminated and then <c>Module:stop(State)</c> is - called.</p> + are terminated and then <c>Module:stop(State)</c> is called.</p> </desc> </func> <func> <name>Module:stop(State)</name> - <fsummary>Clean up after termination of an application</fsummary> + <fsummary>Clean up after termination of an application.</fsummary> <type> <v>State = term()</v> </type> <desc> <p>This function is called whenever an application has stopped. It is intended to be the opposite of <c>Module:start/2</c> - and should do any necessary cleaning up. The return value is + and is to do any necessary cleaning up. The return value is ignored.</p> - <p><c>State</c> is the return value of - <c>Module:prep_stop/1</c>, if such a function exists. - Otherwise <c>State</c> is taken from the return value of - <c>Module:start/2</c>.</p> + <p><c>State</c> is the return value of <c>Module:prep_stop/1</c>, + if such a function exists. Otherwise <c>State</c> is taken from + the return value of <c>Module:start/2</c>.</p> </desc> </func> <func> @@ -572,19 +592,18 @@ Nodes = [cp1@cave, {cp2@cave, cp3@cave}]</code> </type> <desc> <p>This function is called by an application after a code - replacement, if there are any changes to the configuration - parameters.</p> - <p><c>Changed</c> is a list of parameter-value tuples with all - configuration parameters with changed values, <c>New</c> is - a list of parameter-value tuples with all configuration - parameters that have been added, and <c>Removed</c> is a list - of all parameters that have been removed.</p> + replacement, if the configuration parameters have changed.</p> + <p><c>Changed</c> is a list of parameter-value tuples including all + configuration parameters with changed values.</p> + <p><c>New</c> is a list of parameter-value tuples including all + added configuration parameters.</p> + <p><c>Removed</c> is a list of all removed parameters.</p> </desc> </func> </funcs> <section> - <title>SEE ALSO</title> + <title>See Also</title> <p><seealso marker="doc/design_principles:des_princ">OTP Design Principles</seealso>, <seealso marker="kernel_app">kernel(6)</seealso>, <seealso marker="app">app(4)</seealso></p> diff --git a/lib/kernel/doc/src/auth.xml b/lib/kernel/doc/src/auth.xml index 3ff7f16439..03f983b96d 100644 --- a/lib/kernel/doc/src/auth.xml +++ b/lib/kernel/doc/src/auth.xml @@ -29,7 +29,7 @@ <rev></rev> </header> <module>auth</module> - <modulesummary>Erlang Network Authentication Server</modulesummary> + <modulesummary>Erlang network authentication server.</modulesummary> <description> <p>This module is deprecated. For a description of the Magic Cookie system, refer to @@ -42,60 +42,60 @@ </datatypes> <funcs> <func> - <name name="is_auth" arity="1"/> - <fsummary>Status of communication authorization (deprecated)</fsummary> - <desc> - <p>Returns <c>yes</c> if communication with <c><anno>Node</anno></c> is - authorized. Note that a connection to <c><anno>Node</anno></c> will - be established in this case. Returns <c>no</c> if <c><anno>Node</anno></c> - does not exist or communication is not authorized (it has - another cookie than <c>auth</c> thinks it has).</p> - <p>Use <seealso marker="net_adm#ping/1">net_adm:ping(<c><anno>Node</anno></c>)</seealso> - instead.</p> - </desc> - </func> - <func> <name name="cookie" arity="0"/> - <fsummary>Magic cookie for local node (deprecated)</fsummary> + <fsummary>Magic cookie for local node (deprecated).</fsummary> <desc> <p>Use - <seealso marker="erts:erlang#erlang:get_cookie/0">erlang:get_cookie()</seealso> - instead.</p> + <seealso marker="erts:erlang#erlang:get_cookie/0"><c>erlang:get_cookie()</c></seealso> + in <c>ERTS</c> instead.</p> </desc> </func> <func> <name name="cookie" arity="1"/> - <fsummary>Set the magic for the local node (deprecated)</fsummary> + <fsummary>Set the magic for the local node (deprecated).</fsummary> <type_desc variable="TheCookie"> - The cookie may also be given as a list with a single atom element. + The cookie can also be specified as a list with a single atom element. </type_desc> <desc> <p>Use - <seealso marker="erts:erlang#erlang:set_cookie/2">erlang:set_cookie(node(), <c><anno>Cookie</anno></c>)</seealso> + <seealso marker="erts:erlang#erlang:set_cookie/2"><c>erlang:set_cookie(node(), <anno>Cookie</anno>)</c> + in <c>ERTS</c></seealso> instead.</p> + </desc> + </func> + <func> + <name name="is_auth" arity="1"/> + <fsummary>Status of communication authorization (deprecated).</fsummary> + <desc> + <p>Returns <c>yes</c> if communication with <c><anno>Node</anno></c> is + authorized. Notice that a connection to <c><anno>Node</anno></c> + is established in this case. Returns <c>no</c> if <c><anno>Node</anno></c> + does not exist or communication is not authorized (it has + another cookie than <c>auth</c> thinks it has).</p> + <p>Use <seealso marker="net_adm#ping/1"><c>net_adm:ping(<anno>Node</anno>)</c></seealso> instead.</p> </desc> </func> <func> <name>node_cookie([Node, Cookie]) -> yes | no</name> - <fsummary>Set the magic cookie for a node and verify authorization (deprecated)</fsummary> + <fsummary>Set the magic cookie for a node and verify authorization (deprecated).</fsummary> <type> <v>Node = node()</v> - <v>Cookie = <seealso marker="#type-cookie">cookie()</seealso></v> + <v>Cookie = <seealso marker="#type-cookie"><c>cookie()</c></seealso></v> </type> <desc> <p>Equivalent to - <seealso marker="#node_cookie/2">node_cookie(Node, Cookie)</seealso>.</p> + <seealso marker="#node_cookie/2"><c>node_cookie(Node, Cookie)</c></seealso>.</p> </desc> </func> <func> <name name="node_cookie" arity="2"/> - <fsummary>Set the magic cookie for a node and verify authorization (deprecated)</fsummary> + <fsummary>Set the magic cookie for a node and verify authorization (deprecated).</fsummary> <desc> - <p>Sets the magic cookie of <c><anno>Node</anno></c> to <c><anno>Cookie</anno></c>, and - verifies the status of the authorization. + <p>Sets the magic cookie of <c><anno>Node</anno></c> to + <c><anno>Cookie</anno></c> and verifies the status of the authorization. Equivalent to calling - <seealso marker="erts:erlang#erlang:set_cookie/2">erlang:set_cookie(<c><anno>Node</anno></c>, <c><anno>Cookie</anno>)</c></seealso>, followed by - <seealso marker="#is_auth/1">auth:is_auth(<c><anno>Node</anno></c>)</seealso>.</p> + <seealso marker="erts:erlang#erlang:set_cookie/2"><c>erlang:set_cookie(<anno>Node</anno>, <anno>Cookie</anno>)</c></seealso>, followed by + <seealso marker="#is_auth/1"><c>auth:is_auth(<anno>Node</anno>)</c></seealso>.</p> </desc> </func> </funcs> diff --git a/lib/kernel/doc/src/code.xml b/lib/kernel/doc/src/code.xml index 3a63d7edd2..d3611d6a03 100644 --- a/lib/kernel/doc/src/code.xml +++ b/lib/kernel/doc/src/code.xml @@ -29,238 +29,240 @@ <rev></rev> </header> <module>code</module> - <modulesummary>Erlang Code Server</modulesummary> + <modulesummary>Erlang code server.</modulesummary> <description> <p>This module contains the interface to the Erlang <em>code server</em>, which deals with the loading of compiled code into a running Erlang runtime system.</p> - <p>The runtime system can be started in either <em>embedded</em> or - <em>interactive</em> mode. Which one is decided by the command - line flag <c>-mode</c>.</p> + <p>The runtime system can be started in <em>embedded</em> or + <em>interactive</em> mode. Which one is decided by command-line + flag <c>-mode</c>:</p> <pre> % <input>erl -mode interactive</input></pre> - <p>Default mode is <c>interactive</c>.</p> + <p>The modes are as follows:</p> <list type="bulleted"> <item> - <p>In embedded mode, all code is loaded during system start-up + <p>In embedded mode, all code is loaded during system startup according to the boot script. (Code can also be loaded later by explicitly ordering the code server to do so).</p> </item> <item> - <p>In interactive mode, only some code is loaded during system - startup-up, basically the modules needed by the runtime - system itself. Other code is dynamically loaded when first + <p>In interactive mode, which is default, only some code is loaded + during system startup, basically the modules needed by the runtime + system. Other code is dynamically loaded when first referenced. When a call to a function in a certain module is made, and the module is not loaded, the code server searches for and tries to load the module.</p> </item> </list> - <p>To prevent accidentally reloading modules affecting the Erlang - runtime system itself, the <c>kernel</c>, <c>stdlib</c> and - <c>compiler</c> directories are considered <em>sticky</em>. This + <p>To prevent accidentally reloading of modules affecting the Erlang + runtime system, directories <c>kernel</c>, <c>stdlib</c>, + and <c>compiler</c> are considered <em>sticky</em>. This means that the system issues a warning and rejects the request if a user tries to reload a module residing in any of them. - The feature can be disabled by using the command line flag + The feature can be disabled by using command-line flag <c>-nostick</c>.</p> </description> <section> <title>Code Path</title> - <p>In interactive mode, the code server maintains a search path -- - usually called the <em>code path</em> -- consisting of a list of + <p>In interactive mode, the code server maintains a search path, + usually called the <em>code path</em>, consisting of a list of directories, which it searches sequentially when trying to load a module.</p> <p>Initially, the code path consists of the current working - directory and all Erlang object code directories under the library + directory and all Erlang object code directories under library directory <c>$OTPROOT/lib</c>, where <c>$OTPROOT</c> is the installation directory of Erlang/OTP, <c>code:root_dir()</c>. Directories can be named <c>Name[-Vsn]</c> and the code server, by default, chooses the directory with the highest version number - among those which have the same <c>Name</c>. The <c>-Vsn</c> - suffix is optional. If an <c>ebin</c> directory exists under - <c>Name[-Vsn]</c>, it is this directory which is added to - the code path.</p> - <p>The environment variable <c>ERL_LIBS</c> (defined in the operating - system) can be used to define additional library directories that - will be handled in the same way as the standard OTP library - directory described above, except that directories that do not - have an <c>ebin</c> directory will be ignored.</p> + among those having the same <c>Name</c>. Suffix <c>-Vsn</c> + is optional. If an <c>ebin</c> directory exists under + <c>Name[-Vsn]</c>, this directory is added to the code path.</p> + <p>Environment variable <c>ERL_LIBS</c> (defined in the operating + system) can be used to define more library directories to + be handled in the same way as the standard OTP library + directory described above, except that directories without + an <c>ebin</c> directory are ignored.</p> <p>All application directories found in the additional directories - will appear before the standard OTP applications, except for the - Kernel and STDLIB applications, which will be placed before any - additional applications. In other words, modules found in any - of the additional library directories will override modules with - the same name in OTP, except for modules in Kernel and - STDLIB.</p> - <p>The environment variable <c>ERL_LIBS</c> (if defined) should contain + appears before the standard OTP applications, except for the + <c>Kernel</c> and <c>STDLIB</c> applications, which are placed before + any additional applications. In other words, modules found in any + of the additional library directories override modules with + the same name in OTP, except for modules in <c>Kernel</c> and + <c>STDLIB</c>.</p> + <p>Environment variable <c>ERL_LIBS</c> (if defined) is to contain a colon-separated (for Unix-like systems) or semicolon-separated (for Windows) list of additional libraries.</p> - <p>Example: On an Unix-like system, <c>ERL_LIBS</c> could be set to - <c>/usr/local/jungerl:/home/some_user/my_erlang_lib</c>. (On Windows, - use semi-colon as separator.)</p> + <p><em>Example:</em></p> + <p>On a Unix-like system, <c>ERL_LIBS</c> can be set to the following</p> + <code> +/usr/local/jungerl:/home/some_user/my_erlang_lib</code> + <p>On Windows, use semi-colon as separator.</p> </section> <section> <title>Loading of Code From Archive Files</title> - <warning><p>The support for loading of code from archive files is - experimental. The sole purpose of releasing it before it is ready + <warning><p>The support for loading code from archive files is + experimental. The purpose of releasing it before it is ready is to obtain early feedback. The file format, semantics, - interfaces etc. may be changed in a future release. The function - <c>lib_dir/2</c> and the flag <c>-code_path_choice</c> are also + interfaces, and so on, can be changed in a future release. The function + <seealso marker="#lib_dir/2"><c>lib_dir/2</c></seealso> + and flag <c>-code_path_choice</c> are also experimental.</p></warning> - <p>In the current implementation, Erlang archives are <c>ZIP</c> - files with <c>.ez</c> extension. Erlang archives may also be + <p>The Erlang archives are <c>ZIP</c> + files with extension <c>.ez</c>. Erlang archives can also be enclosed in <c>escript</c> files whose file extension is arbitrary.</p> - <p>Erlang archive files may contain entire Erlang applications or + <p>Erlang archive files can contain entire Erlang applications or parts of applications. The structure in an archive file is the - same as the directory structure for an application. If you for - example would create an archive of <c>mnesia-4.4.7</c>, the + same as the directory structure for an application. If you, for + example, create an archive of <c>mnesia-4.4.7</c>, the archive file must be named <c>mnesia-4.4.7.ez</c> and it must - contain a top directory with the name <c>mnesia-4.4.7</c>. If the + contain a top directory named <c>mnesia-4.4.7</c>. If the version part of the name is omitted, it must also be omitted in the archive. That is, a <c>mnesia.ez</c> archive must contain a <c>mnesia</c> top directory.</p> - <p>An archive file for an application may for example be + <p>An archive file for an application can, for example, be created like this:</p> <pre> - zip:create("mnesia-4.4.7.ez", - ["mnesia-4.4.7"], - [{cwd, code:lib_dir()}, - {compress, all}, - {uncompress,[".beam",".app"]}]).</pre> - - <p>Any file in the archive may be compressed, but in order to - speed up the access of frequently read files, it may be a good +zip:create("mnesia-4.4.7.ez", + ["mnesia-4.4.7"], + [{cwd, code:lib_dir()}, + {compress, all}, + {uncompress,[".beam",".app"]}]).</pre> + + <p>Any file in the archive can be compressed, but to + speed up the access of frequently read files, it can be a good idea to store <c>beam</c> and <c>app</c> files uncompressed in the archive.</p> - <p>Normally the top directory of an application is located either - in the library directory <c>$OTPROOT/lib</c> or in a directory - referred to by the environment variable <c>ERL_LIBS</c>. At - startup when the initial code path is computed, the code server - will also look for archive files in these directories and - possibly add <c>ebin</c> directories in archives to the code path. The - code path will then contain paths to directories that looks like + <p>Normally the top directory of an application is located + in library directory <c>$OTPROOT/lib</c> or in a directory + referred to by environment variable <c>ERL_LIBS</c>. At + startup, when the initial code path is computed, the code server + also looks for archive files in these directories and + possibly adds <c>ebin</c> directories in archives to the code path. The + code path then contains paths to directories that look like <c>$OTPROOT/lib/mnesia.ez/mnesia/ebin</c> or <c>$OTPROOT/lib/mnesia-4.4.7.ez/mnesia-4.4.7/ebin</c>.</p> - <p>The code server uses the module <c>erl_prim_loader</c> - (possibly via the <c>erl_boot_server</c>) to read code files from - archives. But the functions in <c>erl_prim_loader</c> may also be + <p>The code server uses module <c>erl_prim_loader</c> in <c>ERTS</c> + (possibly through <c>erl_boot_server</c>) to read code files from + archives. However, the functions in <c>erl_prim_loader</c> can also be used by other applications to read files from archives. For example, the call <c>erl_prim_loader:list_dir( "/otp/root/lib/mnesia-4.4.7.ez/mnesia-4.4.7/examples/bench)"</c> would list the contents of a directory inside an archive. - See <seealso marker="erts:erl_prim_loader">erl_prim_loader(3)</seealso>.</p> + See <seealso marker="erts:erl_prim_loader"><c>erl_prim_loader(3)</c></seealso>.</p> <p>An application archive file and a regular application directory - may coexist. This may be useful when there is a need of having + can coexist. This can be useful when it is needed to have parts of the application as regular files. A typical case is the - <c>priv</c> directory which must reside as a regular directory in - order to be able to dynamically link in drivers and start port - programs. For other applications that do not have this need, the - <c>priv</c> directory may reside in the archive and the files - under the <c>priv</c> directory may be read via the + <c>priv</c> directory, which must reside as a regular directory + to link in drivers dynamically and start port programs. + For other applications that do not need this, directory + <c>priv</c> can reside in the archive and the files + under the directory <c>priv</c> can be read through <c>erl_prim_loader</c>.</p> - <p>At the time point when a directory is added to the code path as - well as when the entire code path is (re)set, the code server - will decide which subdirectories in an application that shall be - read from the archive and which that shall be read as regular + <p>When a directory is added to the code path and + when the entire code path is (re)set, the code server + decides which subdirectories in an application that are to be + read from the archive and which that are to be read as regular files. If directories are added or removed afterwards, the file - access may fail if the code path is not updated (possibly to the - same path as before in order to trigger the directory resolution - update). For each directory on the second level (ebin, priv, src - etc.) in the application archive, the code server will firstly - choose the regular directory if it exists and secondly from the - archive. The function - <c>code:lib_dir/2</c> returns the path to the subdirectory. For - example <c>code:lib_dir(megaco,ebin)</c> may return + access can fail if the code path is not updated (possibly to the + same path as before, to trigger the directory resolution + update).</p> + + <p>For each directory on the second level in the application archive + (<c>ebin</c>, <c>priv</c>, <c>src</c>, and so on), the code server first + chooses the regular directory if it exists and second from the + archive. Function <c>code:lib_dir/2</c> returns the path to the + subdirectory. For example, <c>code:lib_dir(megaco,ebin)</c> can return <c>/otp/root/lib/megaco-3.9.1.1.ez/megaco-3.9.1.1/ebin</c> while - <c>code:lib_dir(megaco,priv)</c> may return + <c>code:lib_dir(megaco,priv)</c> can return <c>/otp/root/lib/megaco-3.9.1.1/priv</c>.</p> <p>When an <c>escript</c> file contains an archive, there are - neither restrictions on the name of the <c>escript</c> nor on how - many applications that may be stored in the embedded - archive. Single <c>beam</c> files may also reside on the top - level in the archive. At startup, both the top directory in the - embedded archive as well as all (second level) <c>ebin</c> + no restrictions on the name of the <c>escript</c> and no restrictions + on how many applications that can be stored in the embedded + archive. Single Beam files can also reside on the top + level in the archive. At startup, the top directory in the + embedded archive and all (second level) <c>ebin</c> directories in the embedded archive are added to the code path. - See <seealso marker="erts:escript">escript(1)</seealso></p> + See <seealso marker="erts:escript"><c>erts:escript(1)</c></seealso>.</p> <p>When the choice of directories in the code path is - <c>strict</c>, the directory that ends up in the code path will - be exactly the stated one. This means that if for example the + <c>strict</c>, the directory that ends up in the code path is + exactly the stated one. This means that if, for example, the directory <c>$OTPROOT/lib/mnesia-4.4.7/ebin</c> is explicitly - added to the code path, the code server will not load files from - <c>$OTPROOT/lib/mnesia-4.4.7.ez/mnesia-4.4.7/ebin</c> and vice - versa. </p> + added to the code path, the code server does not load files from + <c>$OTPROOT/lib/mnesia-4.4.7.ez/mnesia-4.4.7/ebin</c>.</p> - <p>This behavior can be controlled via the command line flag + <p>This behavior can be controlled through command-line flag <c>-code_path_choice Choice</c>. If the flag is set to <c>relaxed</c>, - the code server will instead choose a suitable directory - depending on the actual file structure. If there exists a regular - application ebin directory, it will be chosen. But if it does - not exist, the ebin directory in the archive is chosen if it - exists. If neither of them exists the original directory will be + the code server instead chooses a suitable directory + depending on the actual file structure. If a regular + application <c>ebin</c> directory exists, it is chosen. Otherwise, + the directory <c>ebin</c> in the archive is chosen if it + exists. If neither of them exists, the original directory is chosen.</p> - <p>The command line flag <c>-code_path_choice Choice</c> does also - affect how <c>init</c> interprets the <c>boot script</c>. The - interpretation of the explicit code paths in the <c>boot - script</c> may be <c>strict</c> or <c>relaxed</c>. It is - particular useful to set the flag to <c>relaxed</c> when you want - to elaborate with code loading from archives without editing the + <p>Command-line flag <c>-code_path_choice Choice</c> also + affects how module <c>init</c> interprets the <c>boot script</c>. + The interpretation of the explicit code paths in the <c>boot + script</c> can be <c>strict</c> or <c>relaxed</c>. It is + particularly useful to set the flag to <c>relaxed</c> when + elaborating with code loading from archives without editing the <c>boot script</c>. The default is <c>relaxed</c>. See <seealso - marker="erts:init">init(3)</seealso></p></section> + marker="erts:init"><c>erts:init(3)</c></seealso>.</p></section> <section> <title>Current and Old Code</title> - <p>The code of a module can exists in two variants in a system: + <p>The code for a module can exist in two variants in a system: <em>current code</em> and <em>old code</em>. When a module is - loaded into the system for the first time, the code of the module + loaded into the system for the first time, the module code becomes 'current' and the global <em>export table</em> is updated with references to all functions exported from the module.</p> - <p>If then a new instance of the module is loaded (perhaps because - of the correction of an error), then the code of the previous + <p>If then a new instance of the module is loaded (for example, because of + error correction), the code of the previous instance becomes 'old', and all export entries referring to - the previous instance are removed. After that the new instance is - loaded as if it was loaded for the first time, as described above, - and becomes 'current'.</p> - <p>Both old and current code for a module are valid, and may even be + the previous instance are removed. After that, the new instance is + loaded as for the first time, and becomes 'current'.</p> + <p>Both old and current code for a module are valid, and can even be evaluated concurrently. The difference is that exported functions - in old code are unavailable. Hence there is no way to make a - global call to an exported function in old code, but old code may + in old code are unavailable. Hence, a global call cannot be made + to an exported function in old code, but old code can still be evaluated because of processes lingering in it.</p> - <p>If a third instance of the module is loaded, the code server will - remove (purge) the old code and any processes lingering in it will - be terminated. Then the third instance becomes 'current' and + <p>If a third instance of the module is loaded, the code server + removes (purges) the old code and any processes lingering in it + are terminated. Then the third instance becomes 'current' and the previously current code becomes 'old'.</p> <p>For more information about old and current code, and how to - make a process switch from old to current code, refer to + make a process switch from old to current code, see section + Compilation and Code Loading in the <seealso marker="doc/reference_manual:code_loading">Erlang Reference Manual</seealso>.</p> </section> <section> <title>Argument Types and Invalid Arguments</title> - <p>Generally, module and application names are atoms, while file and directory + <p>Module and application names are atoms, while file and directory names are strings. For backward compatibility reasons, some functions accept both strings and atoms, but a future release will probably only allow the arguments that are documented.</p> - <p>From the R12B release, functions in this module will generally fail with an - exception if they are passed an incorrect type (for instance, an integer or a tuple - where an atom was expected). An error tuple will be returned if the type of the argument - was correct, but there was some other error (for instance, a non-existing directory - was given to <c>set_path/1</c>).</p> + <p>As from Erlang/OTP R12B, functions in this module generally fail with an + exception if they are passed an incorrect type (for example, an integer or a tuple + where an atom is expected). An error tuple is returned if the argument type + is correct, but there are some other errors (for example, a non-existing directory + is specified to <c>set_path/1</c>).</p> </section> <section> @@ -312,33 +314,36 @@ </datatype> <datatype> <name name="prepared_code"/> - <desc>An opaque term holding prepared code.</desc> + <desc><p>An opaque term holding prepared code.</p></desc> </datatype> </datatypes> <funcs> <func> <name name="set_path" arity="1"/> - <fsummary>Set the code server search path</fsummary> + <fsummary>Set the code server search path.</fsummary> <desc> <p>Sets the code path to the list of directories <c><anno>Path</anno></c>.</p> - <p>Returns <c>true</c> if successful, or - <c>{error, bad_directory}</c> if any <c><anno>Dir</anno></c> is not - the name of a directory, or <c>{error, bad_path}</c> if - the argument is invalid.</p> + <p>Returns:</p> + <taglist> + <tag><c>true</c></tag> + <item><p>If successful</p></item> + <tag><c>{error, bad_directory}</c></tag> + <item><p>If any <c><anno>Dir</anno></c> is not a directory name</p></item> + </taglist> </desc> </func> <func> <name name="get_path" arity="0"/> - <fsummary>Return the code server search path</fsummary> + <fsummary>Return the code server search path.</fsummary> <desc> - <p>Returns the code path</p> + <p>Returns the code path.</p> </desc> </func> <func> <name name="add_path" arity="1"/> <name name="add_pathz" arity="1"/> - <fsummary>Add a directory to the end of the code path</fsummary> + <fsummary>Add a directory to the end of the code path.</fsummary> <type name="add_path_ret"/> <desc> <p>Adds <c><anno>Dir</anno></c> to the code path. The directory is added as @@ -351,11 +356,11 @@ </func> <func> <name name="add_patha" arity="1"/> - <fsummary>Add a directory to the beginning of the code path</fsummary> + <fsummary>Add a directory to the beginning of the code path.</fsummary> <type name="add_path_ret"/> <desc> <p>Adds <c><anno>Dir</anno></c> to the beginning of the code path. If - <c><anno>Dir</anno></c> already exists, it is removed from the old + <c><anno>Dir</anno></c> exists, it is removed from the old position in the code path.</p> <p>Returns <c>true</c> if successful, or <c>{error, bad_directory}</c> if <c><anno>Dir</anno></c> is not the name @@ -365,69 +370,81 @@ <func> <name name="add_paths" arity="1"/> <name name="add_pathsz" arity="1"/> - <fsummary>Add directories to the end of the code path</fsummary> + <fsummary>Add directories to the end of the code path.</fsummary> <desc> <p>Adds the directories in <c><anno>Dirs</anno></c> to the end of the code - path. If a <c><anno>Dir</anno></c> already exists, it is not added. This - function always returns <c>ok</c>, regardless of the validity + path. If a <c><anno>Dir</anno></c> exists, it is not added.</p> + <p>Always returns <c>ok</c>, regardless of the validity of each individual <c><anno>Dir</anno></c>.</p> </desc> </func> <func> <name name="add_pathsa" arity="1"/> - <fsummary>Add directories to the beginning of the code path</fsummary> + <fsummary>Add directories to the beginning of the code path.</fsummary> <desc> <p>Adds the directories in <c><anno>Dirs</anno></c> to the beginning of - the code path. If a <c><anno>Dir</anno></c> already exists, it is removed - from the old position in the code path. This function always - returns <c>ok</c>, regardless of the validity of each + the code path. If a <c><anno>Dir</anno></c> exists, it is removed + from the old position in the code path.</p> + <p>Always returns <c>ok</c>, regardless of the validity of each individual <c><anno>Dir</anno></c>.</p> </desc> </func> <func> <name name="del_path" arity="1"/> - <fsummary>Delete a directory from the code path</fsummary> + <fsummary>Delete a directory from the code path.</fsummary> <desc> <p>Deletes a directory from the code path. The argument can be an atom <c><anno>Name</anno></c>, in which case the directory with the name <c>.../<anno>Name</anno>[-Vsn][/ebin]</c> is deleted from the code - path. It is also possible to give the complete directory name - <c><anno>Dir</anno></c> as argument.</p> - <p>Returns <c>true</c> if successful, or <c>false</c> if - the directory is not found, or <c>{error, bad_name}</c> if - the argument is invalid.</p> + path. Also, the complete directory name <c><anno>Dir</anno></c> can be + specified as argument.</p> + <p>Returns:</p> + <taglist> + <tag><c>true</c></tag> + <item><p>If successful</p></item> + <tag><c>false</c></tag> + <item><p>If the directory is not found</p></item> + <tag><c>{error, bad_name}</c></tag> + <item><p>If the argument is invalid</p></item> + </taglist> </desc> </func> <func> <name name="replace_path" arity="2"/> - <fsummary>Replace a directory with another in the code path</fsummary> - <desc> - <p>This function replaces an old occurrence of a directory - named <c>.../<anno>Name</anno>[-Vsn][/ebin]</c>, in the code path, with - <c><anno>Dir</anno></c>. If <c><anno>Name</anno></c> does not exist, it adds the new - directory <c><anno>Dir</anno></c> last in the code path. The new directory - must also be named <c>.../<anno>Name</anno>[-Vsn][/ebin]</c>. This function - should be used if a new version of the directory (library) is + <fsummary>Replace a directory with another in the code path.</fsummary> + <desc> + <p>Replaces an old occurrence of a directory + named <c>.../<anno>Name</anno>[-Vsn][/ebin]</c> in the code path, with + <c><anno>Dir</anno></c>. If <c><anno>Name</anno></c> does not exist, it adds + the new directory <c><anno>Dir</anno></c> last in the code path. The new + directory must also be named <c>.../<anno>Name</anno>[-Vsn][/ebin]</c>. + This function is to be used if a new version of the directory (library) is added to a running system.</p> - <p>Returns <c>true</c> if successful, or - <c>{error, bad_name}</c> if <c><anno>Name</anno></c> is not found, or - <c>{error, bad_directory}</c> if <c><anno>Dir</anno></c> does not exist, or - <c>{error, {badarg, [<anno>Name</anno>, <anno>Dir</anno>]}}</c> if <c><anno>Name</anno></c> or - <c><anno>Dir</anno></c> is invalid.</p> + <p>Returns:</p> + <taglist> + <tag><c>true</c></tag> + <item><p>If successful</p></item> + <tag><c>{error, bad_name}</c></tag> + <item><p>If <c><anno>Name</anno></c> is not found</p></item> + <tag><c>{error, bad_directory}</c></tag> + <item><p>If <c><anno>Dir</anno></c> does not exist</p></item> + <tag><c>{error, {badarg, [<anno>Name</anno>, <anno>Dir</anno>]}}</c></tag> + <item><p>If <c><anno>Name</anno></c> or <c><anno>Dir</anno></c> is invalid</p></item> + </taglist> </desc> </func> <func> <name name="load_file" arity="1"/> - <fsummary>Load a module</fsummary> + <fsummary>Load a module.</fsummary> <type name="load_ret"/> <desc> <p>Tries to load the Erlang module <c><anno>Module</anno></c>, using the code path. It looks for the object code file with an - extension that corresponds to the Erlang machine used, for - example <c><anno>Module</anno>.beam</c>. The loading fails if the module + extension corresponding to the Erlang machine used, for + example, <c><anno>Module</anno>.beam</c>. The loading fails if the module name found in the object code differs from the name <c><anno>Module</anno></c>. - <seealso marker="#load_binary/3">load_binary/3</seealso> must + <seealso marker="#load_binary/3"><c>load_binary/3</c></seealso> must be used to load object code with a module name that is different from the file name.</p> <p>Returns <c>{module, <anno>Module</anno>}</c> if successful, or @@ -437,45 +454,45 @@ </func> <func> <name name="load_abs" arity="1"/> - <fsummary>Load a module, residing in a given file</fsummary> + <fsummary>Load a module, residing in a specified file.</fsummary> <type name="load_ret"/> <type name="loaded_filename"/> <type name="loaded_ret_atoms"/> <desc> - <p>Does the same as <c>load_file(<anno>Module</anno>)</c>, but - <c><anno>Filename</anno></c> is either an absolute file name, or a - relative file name. The code path is not searched. It returns + <p>Same as <c>load_file(<anno>Module</anno>)</c>, but + <c><anno>Filename</anno></c> is an absolute or + relative filename. The code path is not searched. It returns a value in the same way as - <seealso marker="#load_file/1">load_file/1</seealso>. Note - that <c><anno>Filename</anno></c> should not contain the extension (for - example <c>".beam"</c>); <c>load_abs/1</c> adds the correct - extension itself.</p> + <seealso marker="#load_file/1"><c>load_file/1</c></seealso>. Notice + that <c><anno>Filename</anno></c> must not contain the extension (for + example, <c>.beam</c>) because <c>load_abs/1</c> adds the correct + extension.</p> </desc> </func> <func> <name name="ensure_loaded" arity="1"/> - <fsummary>Ensure that a module is loaded</fsummary> + <fsummary>Ensure that a module is loaded.</fsummary> <desc> - <p>Tries to to load a module in the same way as - <seealso marker="#load_file/1">load_file/1</seealso>, + <p>Tries to load a module in the same way as + <seealso marker="#load_file/1"><c>load_file/1</c></seealso>, unless the module is already loaded. - In embedded mode, however, it does not load a module which is not + However, in embedded mode it does not load a module that is not already loaded, but returns <c>{error, embedded}</c> instead. See <seealso marker="#error_reasons">Error Reasons for Code-Loading Functions</seealso> for a description of other possible error reasons.</p> </desc> </func> <func> <name name="load_binary" arity="3"/> - <fsummary>Load object code for a module</fsummary> + <fsummary>Load object code for a module.</fsummary> <type name="loaded_filename"/> <type name="loaded_ret_atoms"/> <desc> <p>This function can be used to load object code on remote - Erlang nodes. The argument <c><anno>Binary</anno></c> must contain + Erlang nodes. Argument <c><anno>Binary</anno></c> must contain object code for <c><anno>Module</anno></c>. <c><anno>Filename</anno></c> is only used by the code server to keep a record of from which file the object code for <c><anno>Module</anno></c> - comes. Accordingly, <c><anno>Filename</anno></c> is not opened and read by + comes. Thus, <c><anno>Filename</anno></c> is not opened and read by the code server.</p> <p>Returns <c>{module, <anno>Module</anno>}</c> if successful, or <c>{error, Reason}</c> if loading fails. @@ -616,92 +633,94 @@ ok = code:finish_loading(Prepared), </func> <func> <name name="delete" arity="1"/> - <fsummary>Removes current code for a module</fsummary> + <fsummary>Remove current code for a module.</fsummary> <desc> <p>Removes the current code for <c><anno>Module</anno></c>, that is, the current code for <c><anno>Module</anno></c> is made old. This means that processes can continue to execute the code in the module, - but that no external function calls can be made to it.</p> + but no external function calls can be made to it.</p> <p>Returns <c>true</c> if successful, or <c>false</c> if there - is old code for <c><anno>Module</anno></c> which must be purged first, or + is old code for <c><anno>Module</anno></c> that must be purged first, or if <c><anno>Module</anno></c> is not a (loaded) module.</p> </desc> </func> <func> <name name="purge" arity="1"/> - <fsummary>Removes old code for a module</fsummary> + <fsummary>Remove old code for a module.</fsummary> <desc> <p>Purges the code for <c><anno>Module</anno></c>, that is, removes code marked as old. If some processes still linger in the old code, these processes are killed before the code is removed.</p> - <p>Returns <c>true</c> if successful and any process needed to + <p>Returns <c>true</c> if successful and any process is needed to be killed, otherwise <c>false</c>.</p> </desc> </func> <func> <name name="soft_purge" arity="1"/> - <fsummary>Removes old code for a module, unless no process uses it</fsummary> + <fsummary>Remove old code for a module, unless no process uses it.</fsummary> <desc> <p>Purges the code for <c><anno>Module</anno></c>, that is, removes code marked as old, but only if no processes linger in it.</p> - <p>Returns <c>false</c> if the module could not be purged due - to processes lingering in old code, otherwise <c>true</c>.</p> + <p>Returns <c>false</c> if the module cannot be purged because + of processes lingering in old code, otherwise <c>true</c>.</p> </desc> </func> <func> <name name="is_loaded" arity="1"/> - <fsummary>Check if a module is loaded</fsummary> + <fsummary>Check if a module is loaded.</fsummary> <type name="loaded_filename"/> <type name="loaded_ret_atoms"/> - <type_desc name="loaded_filename"><c><anno>Filename</anno></c> is an absolute filename</type_desc> + <type_desc name="loaded_filename"><c><anno>Filename</anno></c> is an absolute + filename.</type_desc> <desc> <p>Checks if <c><anno>Module</anno></c> is loaded. If it is, <c>{file, <anno>Loaded</anno>}</c> is returned, otherwise <c>false</c>.</p> - <p>Normally, <c><anno>Loaded</anno></c> is the absolute file name - <c>Filename</c> from which the code was obtained. If the module + <p>Normally, <c><anno>Loaded</anno></c> is the absolute filename + <c>Filename</c> from which the code is obtained. If the module is preloaded (see - <seealso marker="sasl:script">script(4)</seealso>), - <c>Loaded==preloaded</c>. If the module is Cover compiled (see - <seealso marker="tools:cover">cover(3)</seealso>), + <seealso marker="sasl:script"><c>sasl:script(4)</c></seealso>), + <c>Loaded==preloaded</c>. If the module is Cover-compiled (see + <seealso marker="tools:cover"><c>tools:cover(3)</c></seealso>), <c>Loaded==cover_compiled</c>.</p> </desc> </func> <func> <name name="all_loaded" arity="0"/> - <fsummary>Get all loaded modules</fsummary> + <fsummary>Get all loaded modules.</fsummary> <type name="loaded_filename"/> <type name="loaded_ret_atoms"/> - <type_desc name="loaded_filename"><c><anno>Filename</anno></c> is an absolute filename</type_desc> + <type_desc name="loaded_filename"><c><anno>Filename</anno></c> is an absolute + filename.</type_desc> <desc> <p>Returns a list of tuples <c>{<anno>Module</anno>, <anno>Loaded</anno>}</c> for all - loaded modules. <c><anno>Loaded</anno></c> is normally the absolute file - name, as described for - <seealso marker="#is_loaded/1">is_loaded/1</seealso>.</p> + loaded modules. <c><anno>Loaded</anno></c> is normally the absolute filename, + as described for + <seealso marker="#is_loaded/1"><c>is_loaded/1</c></seealso>.</p> </desc> </func> <func> <name name="which" arity="1"/> - <fsummary>The object code file of a module</fsummary> + <fsummary>The object code file of a module.</fsummary> <type name="loaded_ret_atoms"/> <desc> <p>If the module is not loaded, this function searches the code - path for the first file which contains object code for - <c><anno>Module</anno></c> and returns the absolute file name. If - the module is loaded, it returns the name of the file which - contained the loaded object code. If the module is pre-loaded, - <c>preloaded</c> is returned. If the module is Cover compiled, - <c>cover_compiled</c> is returned. <c>non_existing</c> is - returned if the module cannot be found.</p> + path for the first file containing object code for + <c><anno>Module</anno></c> and returns the absolute filename.</p> + <p>If the module is loaded, it returns the name of the file + containing the loaded object code.</p> + <p>If the module is preloaded, <c>preloaded</c> is returned.</p> + <p>If the module is Cover-compiled, <c>cover_compiled</c> is returned.</p> + <p>If the module cannot be found, <c>non_existing</c> is returned.</p> </desc> </func> <func> <name name="get_object_code" arity="1"/> - <fsummary>Get the object code for a module</fsummary> + <fsummary>Gets the object code for a module.</fsummary> <desc> - <p>Searches the code path for the object code of the module - <c><anno>Module</anno></c>. It returns <c>{<anno>Module</anno>, <anno>Binary</anno>, <anno>Filename</anno>}</c> - if successful, and <c>error</c> if not. <c><anno>Binary</anno></c> is a - binary data object which contains the object code for + <p>Searches the code path for the object code of module + <c><anno>Module</anno></c>. Returns <c>{<anno>Module</anno>, <anno>Binary</anno>, <anno>Filename</anno>}</c> + if successful, otherwise <c>error</c>. <c><anno>Binary</anno></c> is a + binary data object, which contains the object code for the module. This can be useful if code is to be loaded on a remote node in a distributed system. For example, loading module <c><anno>Module</anno></c> on a node <c>Node</c> is done as @@ -715,10 +734,11 @@ rpc:call(Node, code, load_binary, [Module, Filename, Binary]), </func> <func> <name name="root_dir" arity="0"/> - <fsummary>Root directory of Erlang/OTP</fsummary> + <fsummary>Root directory of Erlang/OTP.</fsummary> <desc> <p>Returns the root directory of Erlang/OTP, which is the directory where it is installed.</p> + <p><em>Example:</em></p> <pre> > <input>code:root_dir().</input> "/usr/local/otp"</pre> @@ -726,10 +746,11 @@ rpc:call(Node, code, load_binary, [Module, Filename, Binary]), </func> <func> <name name="lib_dir" arity="0"/> - <fsummary>Library directory of Erlang/OTP</fsummary> + <fsummary>Library directory of Erlang/OTP.</fsummary> <desc> <p>Returns the library directory, <c>$OTPROOT/lib</c>, where <c>$OTPROOT</c> is the root directory of Erlang/OTP.</p> + <p><em>Example:</em></p> <pre> > <input>code:lib_dir().</input> "/usr/local/otp/lib"</pre> @@ -737,50 +758,49 @@ rpc:call(Node, code, load_binary, [Module, Filename, Binary]), </func> <func> <name name="lib_dir" arity="1"/> - <fsummary>Library directory for an application</fsummary> + <fsummary>Library directory for an application.</fsummary> <desc> - <p>This function is mainly intended for finding out the path + <p>Returns the path for the "library directory", the top directory, for an application <c><anno>Name</anno></c> located under <c>$OTPROOT/lib</c> or - on a directory referred to via the <c>ERL_LIBS</c> - environment variable.</p> - <p>If there is a regular directory called <c><anno>Name</anno></c> or - <c><anno>Name</anno>-Vsn</c> in the code path with an <c>ebin</c> + on a directory referred to with environment variable <c>ERL_LIBS</c>.</p> + <p>If a regular directory called <c><anno>Name</anno></c> or + <c><anno>Name</anno>-Vsn</c> exists in the code path with an <c>ebin</c> subdirectory, the path to this directory is returned (not - the <c>ebin</c> directory). If the directory refers to a - directory in an archive, the archive name is stripped away - before the path is returned. For example, if the directory + the <c>ebin</c> directory).</p> + <p>If the directory refers to a directory in an archive, the + archive name is stripped away before the path is returned. + For example, if directory <c>/usr/local/otp/lib/mnesia-4.2.2.ez/mnesia-4.2.2/ebin</c> is in the path, <c>/usr/local/otp/lib/mnesia-4.2.2/ebin</c> - will be returned. This means that the library directory for - an application is the same, regardless of whether the + is returned. This means that the library directory for + an application is the same, regardless if the application resides in an archive or not.</p> - + <p><em>Example:</em></p> <pre> > <input>code:lib_dir(mnesia).</input> "/usr/local/otp/lib/mnesia-4.2.2"</pre> <p>Returns <c>{error, bad_name}</c> if <c><anno>Name</anno></c> is not the name of an application under <c>$OTPROOT/lib</c> or - on a directory referred to via the <c>ERL_LIBS</c> - environment variable. Fails with an exception if <c>Name</c> - has the wrong type.</p> + on a directory referred to through environment variable <c>ERL_LIBS</c>. + Fails with an exception if <c>Name</c> has the wrong type.</p> - <warning><p>For backward compatibility, <c><anno>Name</anno></c> is also allowed to - be a string. That will probably change in a future release.</p></warning> + <warning><p>For backward compatibility, <c><anno>Name</anno></c> is also + allowed to be a string. That will probably change in a future release.</p></warning> </desc> </func> <func> <name name="lib_dir" arity="2"/> - <fsummary>subdirectory for an application</fsummary> + <fsummary>Subdirectory for an application.</fsummary> <desc> <p>Returns the path to a subdirectory directly under the top directory of an application. Normally the subdirectories - resides under the top directory for the application, but when - applications at least partly resides in an archive the - situation is different. Some of the subdirectories may reside - as regular directories while other resides in an archive - file. It is not checked if this directory really exists.</p> - + reside under the top directory for the application, but when + applications at least partly resides in an archive, the + situation is different. Some of the subdirectories can reside + as regular directories while other reside in an archive + file. It is not checked whether this directory exists.</p> + <p><em>Example:</em></p> <pre> > <input>code:lib_dir(megaco, priv).</input> "/usr/local/otp/lib/megaco-3.9.1.1/priv"</pre> @@ -791,7 +811,7 @@ rpc:call(Node, code, load_binary, [Module, Filename, Binary]), </func> <func> <name name="compiler_dir" arity="0"/> - <fsummary>Library directory for the compiler</fsummary> + <fsummary>Library directory for the compiler.</fsummary> <desc> <p>Returns the compiler library directory. Equivalent to <c>code:lib_dir(compiler)</c>.</p> @@ -799,10 +819,10 @@ rpc:call(Node, code, load_binary, [Module, Filename, Binary]), </func> <func> <name name="priv_dir" arity="1"/> - <fsummary>Priv directory for an application</fsummary> + <fsummary>Priv directory for an application.</fsummary> <desc> <p>Returns the path to the <c>priv</c> directory in an - application. Equivalent to <c>code:lib_dir(<anno>Name</anno>, priv).</c>.</p> + application. Equivalent to <c>code:lib_dir(<anno>Name</anno>, priv)</c>.</p> <warning><p>For backward compatibility, <c><anno>Name</anno></c> is also allowed to be a string. That will probably change in a future release.</p></warning> @@ -810,43 +830,43 @@ rpc:call(Node, code, load_binary, [Module, Filename, Binary]), </func> <func> <name name="objfile_extension" arity="0"/> - <fsummary>Object code file extension</fsummary> + <fsummary>Object code file extension.</fsummary> <desc> - <p>Returns the object code file extension that corresponds to - the Erlang machine used, namely <c>".beam"</c>.</p> + <p>Returns the object code file extension corresponding to + the Erlang machine used, namely <c>.beam</c>.</p> </desc> </func> <func> <name name="stick_dir" arity="1"/> - <fsummary>Mark a directory as sticky</fsummary> + <fsummary>Mark a directory as sticky.</fsummary> <desc> - <p>This function marks <c><anno>Dir</anno></c> as sticky.</p> - <p>Returns <c>ok</c> if successful or <c>error</c> if not.</p> + <p>Marks <c><anno>Dir</anno></c> as sticky.</p> + <p>Returns <c>ok</c> if successful, otherwise <c>error</c>.</p> </desc> </func> <func> <name name="unstick_dir" arity="1"/> - <fsummary>Remove a sticky directory mark</fsummary> + <fsummary>Remove a sticky directory mark.</fsummary> <desc> - <p>This function unsticks a directory which has been marked as + <p>Unsticks a directory that is marked as sticky.</p> - <p>Returns <c>ok</c> if successful or <c>error</c> if not.</p> + <p>Returns <c>ok</c> if successful, otherwise <c>error</c>.</p> </desc> </func> <func> <name name="is_sticky" arity="1"/> - <fsummary>Test whether a module is sticky</fsummary> + <fsummary>Test if a module is sticky.</fsummary> <desc> - <p>This function returns <c>true</c> if <c><anno>Module</anno></c> is the + <p>Returns <c>true</c> if <c><anno>Module</anno></c> is the name of a module that has been loaded from a sticky directory - (or in other words: an attempt to reload the module will fail), + (in other words: an attempt to reload the module will fail), or <c>false</c> if <c><anno>Module</anno></c> is not a loaded module or is not sticky.</p> </desc> </func> <func> <name name="where_is_file" arity="1"/> - <fsummary>Full name of a file located in the code path</fsummary> + <fsummary>Full name of a file located in the code path.</fsummary> <desc> <p>Searches the code path for <c><anno>Filename</anno></c>, a file of arbitrary type. If found, the full name is returned. @@ -859,32 +879,39 @@ rpc:call(Node, code, load_binary, [Module, Filename, Binary]), <name name="clash" arity="0"/> <fsummary>Search for modules with identical names.</fsummary> <desc> - <p>Searches the entire code space for module names with + <p>Searches all directories in the code path for module names with identical names and writes a report to <c>stdout</c>.</p> </desc> </func> <func> <name name="is_module_native" arity="1"/> - <fsummary>Test whether a module has native code</fsummary> + <fsummary>Test if a module has native code.</fsummary> <desc> - <p>This function returns <c>true</c> if <c><anno>Module</anno></c> is - name of a loaded module that has native code loaded, and - <c>false</c> if <c><anno>Module</anno></c> is loaded but does not have - native. If <c><anno>Module</anno></c> is not loaded, this function returns - <c>undefined</c>.</p> + <p>Returns:</p> + <taglist> + <tag><c>true</c></tag> + <item><p>If <c><anno>Module</anno></c> is the + name of a loaded module that has native code loaded</p></item> + <tag><c>false</c></tag> + <item><p>If <c><anno>Module</anno></c> is loaded but does not have + native code</p></item> + <tag><c>undefined</c></tag> + <item><p>If <c><anno>Module</anno></c> is not loaded</p></item> + </taglist> </desc> </func> <func> <name name="get_mode" arity="0"/> - <fsummary>The code_server's mode.</fsummary> + <fsummary>The mode of the code server.</fsummary> <desc> - <p>This function returns an atom describing the code_server's mode: - <c>interactive</c> or <c>embedded</c>. </p> + <p>Returns an atom describing the mode of the code server: + <c>interactive</c> or <c>embedded</c>.</p> <p>This information is useful when an external entity (for example, - an IDE) provides additional code for a running node. If in interactive - mode, it only needs to add to the code path. If in embedded mode, - the code has to be loaded with <c>load_binary/3</c></p> + an IDE) provides additional code for a running node. If the code server is + in interactive mode, it only has to add the path to the code. If the code server + is in embedded mode, the code must be loaded with + <seealso marker="#load_binary/3"><c>load_binary/3</c></seealso>.</p> </desc> </func> </funcs> diff --git a/lib/kernel/doc/src/config.xml b/lib/kernel/doc/src/config.xml index 0ec28d8974..c5f37fd036 100644 --- a/lib/kernel/doc/src/config.xml +++ b/lib/kernel/doc/src/config.xml @@ -11,7 +11,7 @@ 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 @@ -19,7 +19,7 @@ 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> <title>config</title> @@ -33,94 +33,93 @@ <description> <p>A <em>configuration file</em> contains values for configuration parameters for the applications in the system. The <c>erl</c> - command line argument <c>-config Name</c> tells the system to use + command-line argument <c>-config Name</c> tells the system to use data in the system configuration file <c>Name.config</c>.</p> - <p>Configuration parameter values in the configuration file will + <p>Configuration parameter values in the configuration file override the values in the application resource files (see - <c>app(4)</c>). The values in the configuration file can be - overridden by command line flags (see <c>erl(1)</c>).</p> + <seealso marker="app"><c>app(4)</c></seealso>. + The values in the configuration file can be + overridden by command-line flags (see + <seealso marker="erts:erl"><c>erts:erl(1)</c></seealso>.</p> <p>The value of a configuration parameter is retrieved by calling <c>application:get_env/1,2</c>.</p> </description> <section> - <title>FILE SYNTAX</title> - <p>The configuration file should be called <c>Name.config</c> where - <c>Name</c> is an arbitrary name.</p> - <p>The <c>.config</c> file contains one single Erlang term. - The file has the following syntax:</p> + <title>File Syntax</title> + <p>The configuration file is to be called <c>Name.config</c>, where + <c>Name</c> is any name.</p> + <p>File <c>.config</c> contains a single Erlang term and + has the following syntax:</p> <code type="none"> -[{Application1, [{Par11, Val11}, ..]}, - .. - {ApplicationN, [{ParN1, ValN1}, ..]}].</code> - <list type="bulleted"> - <item> - <p><c>Application = atom()</c> is the name of the application.</p> - </item> - <item> - <p><c>Par = atom()</c> is the name of a configuration parameter.</p> - </item> - <item> - <p><c>Val = term()</c> is the value of a configuration - parameter.</p> - </item> - </list> +[{Application1, [{Par11, Val11}, ...]}, + ... + {ApplicationN, [{ParN1, ValN1}, ...]}].</code> + <taglist> + <tag><c>Application = atom()</c></tag> + <item><p>Application name.</p></item> + <tag><c>Par = atom()</c></tag> + <item><p>Name of a configuration parameter.</p></item> + <tag><c>Val = term()</c></tag> + <item><p>Value of a configuration parameter.</p></item> + </taglist> </section> <section> <title>sys.config</title> <p>When starting Erlang in embedded mode, it is assumed that exactly one system configuration file is used, named - <c>sys.config</c>. This file should be located in + <c>sys.config</c>. This file is to be located in <c>$ROOT/releases/Vsn</c>, where <c>$ROOT</c> is the Erlang/OTP root installation directory and <c>Vsn</c> is the release version.</p> <p>Release handling relies on this assumption. When installing a new release version, the new <c>sys.config</c> is read and used to update the application configurations.</p> - <p>This means that specifying another, or additional, <c>.config</c> - files would lead to inconsistent update of application + <p>This means that specifying another <c>.config</c> file, or more + <c>.config</c> files, leads to inconsistent update of application configurations. Therefore, in Erlang 5.4/OTP R10B, the syntax of <c>sys.config</c> was extended to allow pointing out other <c>.config</c> files:</p> <code type="none"> [{Application, [{Par, Val}]} | File].</code> - <list type="bulleted"> - <item> - <p><c>File = string()</c> is the name of another <c>.config</c> - file. The extension <c>.config</c> may be omitted. It is - recommended to use absolute paths. A relative path is - relative the current working directory of the emulator.</p> - </item> - </list> + <taglist> + <tag><c>File = string()</c></tag> + <item>Name of another <c>.config</c> file. + Extension <c>.config</c> can be omitted. It is + recommended to use absolute paths. A relative path is + relative the current working directory of the emulator.</item> + </taglist> <p>When traversing the contents of <c>sys.config</c> and a filename is encountered, its contents are read and merged with the result so far. When an application configuration tuple <c>{Application, Env}</c> is found, it is merged with the result so far. Merging means that new parameters are added and existing - parameter values overwritten. Example:</p> + parameter values overwritten.</p> + <p><em>Example:</em></p> <code type="none"> sys.config: [{myapp,[{par1,val1},{par2,val2}]}, "/home/user/myconfig"]. - myconfig.config: [{myapp,[{par2,val3},{par3,val4}]}].</code> - <p>This will yield the following environment for <c>myapp</c>:</p> + <p>This yields the following environment for <c>myapp</c>:</p> <code type="none"> [{par1,val1},{par2,val3},{par3,val4}]</code> - <p>The behaviour if a file specified in <c>sys.config</c> does not - exist or is erroneous in some other way, is backwards compatible. + <p>The behavior if a file specified in <c>sys.config</c> does not + exist, or is erroneous, is backwards compatible. Starting the runtime system will fail. Installing a new release - version will not fail, but an error message is given and + version will not fail, but an error message is returned and the erroneous file is ignored.</p> </section> <section> - <title>SEE ALSO</title> - <p><c>app(4)</c>, <c>erl(1)</c>, <em>OTP Design Principles</em></p> + <title>See Also</title> + <p><seealso marker="app"><c>app(4)</c></seealso>, + <seealso marker="erts:erl"><c>erts:erl(1)</c></seealso>, + <seealso marker="doc/design_principles:des_princ">OTP Design Principles</seealso></p> </section> </fileref> diff --git a/lib/kernel/doc/src/disk_log.xml b/lib/kernel/doc/src/disk_log.xml index 50a1537c24..0b6ee1e6a5 100644 --- a/lib/kernel/doc/src/disk_log.xml +++ b/lib/kernel/doc/src/disk_log.xml @@ -35,149 +35,174 @@ <file>disk_log.sgml</file> </header> <module>disk_log</module> - <modulesummary>A disk based term logging facility</modulesummary> + <modulesummary>A disk-based term logging facility.</modulesummary> <description> - <p><c>disk_log</c> is a disk based term logger which makes - it possible to efficiently log items on files. - Two types of logs are supported, - <em>halt logs</em> and <em>wrap logs</em>. A halt log - appends items to a single file, the size of which may or may - not be limited by the disk log module, whereas a wrap log utilizes - a sequence of wrap log files of limited size. As a wrap log file - has been filled up, further items are logged onto to the next - file in the sequence, starting all over with the first file when - the last file has been filled up. For the sake of efficiency, - items are always written to files as binaries. - </p> - <p>Two formats of the log files are supported, the <em>internal format</em> and the <em>external format</em>. The internal - format supports automatic repair of log files that have not been - properly closed, and makes it possible to efficiently read - logged items in <em>chunks</em> using a set of functions defined - in this module. In fact, this is the only way to read internally - formatted logs. The external format leaves it up to the user to - read the logged deep byte lists. The disk log module cannot - repair externally formatted logs. An item logged to an - internally formatted log must not occupy more than 4 GB of disk - space (the size must fit in 4 bytes). - </p> - <p>For each open disk log there is one process that handles requests - made to the disk log; the disk log process is created when <c>open/1</c> + <p><c>disk_log</c> is a disk-based term logger that enables + efficient logging of items on files.</p> + <p>Two types of logs are supported:</p> + <taglist> + <tag>halt logs</tag> + <item><p>Appends items to a single file, which size can + be limited by the disk log module.</p></item> + <tag>wrap logs</tag> + <item><p>Uses a sequence of wrap log files of limited size. As a + wrap log file is filled up, further items are logged on to the next + file in the sequence, starting all over with the first file when + the last file is filled up.</p></item> + </taglist> + <p>For efficiency reasons, items are always written to files as binaries.</p> + + <p>Two formats of the log files are supported:</p> + <taglist> + <tag>internal format</tag> + <item><p>Supports automatic repair of log files that are not + properly closed and enables efficient reading of logged items in + <em>chunks</em> using a set of functions defined in this module. + This is the only way to read internally formatted logs. + An item logged to an internally formatted log must not occupy more + than 4 GB of disk space (the size must fit in 4 bytes).</p></item> + <tag>external format</tag> + <item><p>Leaves it up to the user to read the logged deep byte lists. + The disk log module cannot repair externally formatted logs.</p></item> + </taglist> + + <p>For each open disk log, one process handles requests + made to the disk log. This process is created when + <seealso marker="#open/1"><c>open/1</c></seealso> is called, provided there exists no process handling the disk log. - A process that opens a disk log can either be an <em>owner</em> + A process that opens a disk log can be an <em>owner</em> or an anonymous <em>user</em> of the disk log. Each owner is - linked to the disk log - process, and the disk log is closed by the owner should the - owner terminate. Owners can subscribe to <em>notifications</em>, - messages of the form <c>{disk_log, Node, Log, Info}</c> that are sent + linked to the disk log process, and an owner can close the disk log + either explicitly (by calling <c>close/1</c> or <c>lclose/1,2</c>) + or by terminating.</p> + <p>Owners can subscribe to <em>notifications</em>, + messages of the form <c>{disk_log, Node, Log, Info}</c>, which are sent from the disk log process when certain events occur, see - the commands below and in particular the <c>open/1</c> option - <seealso marker="#notify">notify</seealso>. - There can be several owners of a log, but a process cannot own a - log more than once. One and the same process may, however, - open the log - as a user more than once. For a disk log process to properly close - its file and terminate, it must be closed by its owners and once by - some non-owner process for each time the log was used anonymously; - the users are counted, and there must not be any users left when the - disk log process terminates. + the functions and in particular the <c>open/1</c> option + <seealso marker="#notify"><c>notify</c></seealso>. + A log can have many owners, but a process cannot own a + log more than once. However, the same process can open the log + as a user more than once.</p> + <p>For a disk log process to close its file properly and terminate, + it must be closed by its owners and once by some non-owner process + for each time the log was used anonymously. The users are counted + and there must not be any users left when the disk log process terminates. </p> - <p>Items can be logged <em>synchronously</em> by using the functions - <c>log/2</c>, <c>blog/2</c>, <c>log_terms/2</c> and - <c>blog_terms/2</c>. For each of these functions, the caller is put - on hold until the items have been logged (but not necessarily + <p>Items can be logged <em>synchronously</em> by using functions + <seealso marker="#log/2"><c>log/2</c></seealso>, + <seealso marker="#blog/2"><c>blog/2</c></seealso>, + <seealso marker="#log_terms/2"><c>log_terms/2</c></seealso>, and + <seealso marker="#blog_terms/2"><c>blog_terms/2</c></seealso>. + For each of these functions, the caller is put + on hold until the items are logged (but not necessarily written, use <c>sync/1</c> to ensure that). By adding an <c>a</c> - to each of the mentioned function names we get functions that log + to each of the mentioned function names, we get functions that log items <em>asynchronously</em>. Asynchronous functions do not wait for - the disk log process to actually write the items to the file, but + the disk log process to write the items to the file, but return the control to the caller more or less immediately. </p> - <p>When using the internal format for logs, the functions - <c>log/2</c>, <c>log_terms/2</c>, <c>alog/2</c>, and - <c>alog_terms/2</c> should be used. These functions log one or - more Erlang terms. By prefixing each of the functions with - a <c>b</c> (for "binary") we get the corresponding <c>blog</c> - functions for the external format. These functions log one or - more deep lists of bytes or, alternatively, binaries of deep lists - of bytes. - For example, to log the string <c>"hello"</c> in ASCII format, we + <p>When using the internal format for logs, use functions + <seealso marker="#log/2"><c>log/2</c></seealso>, + <seealso marker="#log_terms/2"><c>log_terms/2</c></seealso>, + <seealso marker="#alog/2"><c>alog/2</c></seealso>, and + <seealso marker="#alog_terms/2"><c>alog_terms/2</c></seealso>. + These functions log one or more Erlang terms. + By prefixing each of the functions with a <c>b</c> (for "binary"), + we get the corresponding <c>blog()</c> functions for the external format. + These functions log one or more deep lists of bytes or, alternatively, + binaries of deep lists of bytes. + For example, to log the string <c>"hello"</c> in ASCII format, you can use <c>disk_log:blog(Log, "hello")</c>, or <c>disk_log:blog(Log, list_to_binary("hello"))</c>. The two - alternatives are equally efficient. The <c>blog</c> functions - can be used for internally formatted logs as well, but in - this case they must be called with binaries constructed with - calls to <c>term_to_binary/1</c>. There is no check to ensure + alternatives are equally efficient.</p> + <p>The <c>blog()</c> functions can also be used for internally formatted + logs, but in this case they must be called with binaries constructed + with calls to + <seealso marker="erts:erlang#term_to_binary/1"><c>term_to_binary/1</c></seealso>. + There is no check to ensure this, it is entirely the responsibility of the caller. If these functions are called with binaries that do not correspond to - Erlang terms, the <c>chunk/2,3</c> and automatic repair - functions will fail. The corresponding terms (not the binaries) - will be returned when <c>chunk/2,3</c> is called. + Erlang terms, the + <seealso marker="#chunk/2"><c>chunk/2,3</c></seealso> + and automatic repair + functions fail. The corresponding terms (not the binaries) + are returned when <c>chunk/2,3</c> is called. </p> <p>A collection of open disk logs with the same name running on - different nodes is said to be a <em>a distributed disk log</em> - if requests made to any one of the logs are automatically made to - the other logs as well. The members of such a collection will be + different nodes is said to be a <em>distributed disk log</em> + if requests made to any of the logs are automatically made to + the other logs as well. The members of such a collection are called individual distributed disk logs, or just distributed disk logs if there is no risk of confusion. There is no order - between the members of such a collection. For instance, logged - terms are not necessarily written onto the node where the - request was made before written onto the other nodes. One could - note here that there are a few functions that do not make - requests to all members of distributed disk logs, namely - <c>info</c>, <c>chunk</c>, <c>bchunk</c>, <c>chunk_step</c> and - <c>lclose</c>. An open disk log that is not a distributed disk + between the members of such a collection. For example, logged + terms are not necessarily written to the node where the + request was made before written to the other nodes. However, + a few functions do not make requests to all + members of distributed disk logs, namely + <seealso marker="#info/1"><c>info/1</c></seealso>, + <seealso marker="#chunk/2"><c>chunk/2,3</c></seealso>, + <seealso marker="#bchunk/2"><c>bchunk/2,3</c></seealso>, + <seealso marker="#chunk_step/3"><c>chunk_step/3</c></seealso>, and + <seealso marker="#lclose/1"><c>lclose/1,2</c></seealso>.</p> + <p>An open disk log that is not a distributed disk log is said to be a <em>local disk log</em>. A local disk log is - accessible only from the node where the disk log process runs, + only accessible from the node where the disk log process runs, whereas a distributed disk log is accessible from all nodes in - the Erlang system, with exception for those nodes where a local + the Erlang system, except for those nodes where a local disk log with the same name as the distributed disk log exists. All processes on nodes that have access to a local or - distributed disk log can log items or otherwise change, inspect + distributed disk log can log items or otherwise change, inspect, or close the log. </p> <p>It is not guaranteed that all log files of a distributed disk log - contain the same log items; there is no attempt made to synchronize + contain the same log items. No attempt is made to synchronize the contents of the files. However, as long as at least one of - the involved nodes is alive at each time, all items will be logged. + the involved nodes is alive at each time, all items are logged. When logging items to a distributed log, or otherwise trying to change the log, the replies from individual logs are ignored. If all nodes are down, the disk log functions reply with a <c>nonode</c> error. </p> <note> - <p>In some applications it may not be acceptable that + <p>In some applications, it can be unacceptable that replies from individual logs are ignored. An alternative in such - situations is to use several local disk logs instead of one + situations is to use many local disk logs instead of one distributed disk log, and implement the distribution without use - of the disk log module.</p> + of the <c>disk_log</c> module.</p> </note> <p>Errors are reported differently for asynchronous log attempts - and other uses of the disk log module. When used synchronously - the disk log module replies with an error message, but when called - asynchronously, the disk log module does not know where to send - the error message. Instead owners subscribing to notifications will + and other uses of the <c>disk_log</c> module. When used synchronously, + this module replies with an error message, but when called + asynchronously, this module does not know where to send + the error message. Instead, owners subscribing to notifications receive an <c>error_status</c> message. </p> - <p>The disk log module itself does not report errors to the - <c>error_logger</c> module; it is up to the caller to decide - whether the error logger should be employed or not. The function - <c>format_error/1</c> can be used to produce readable messages - from error replies. Information events are however sent to the - error logger in two situations, namely when a log is repaired, - or when a file is missing while reading chunks. + <p>The <c>disk_log</c> module does not report errors to the + <seealso marker="error_logger"><c>error_logger</c></seealso> + module. It is up to the caller to decide + whether to employ the error logger. Function + <seealso marker="#format_error/1"><c>format_error/1</c></seealso> + can be used to produce readable messages from error replies. + However, information events are sent to the error logger in two + situations, namely when a log is repaired, or when a file is missing + while reading chunks. </p> - <p>The error message <c>no_such_log</c> means that the given - disk log is not currently open. Nothing is said about - whether the disk log files exist or not. + <p>Error message <c>no_such_log</c> means that the specified + disk log is not open. Nothing is said about whether the disk log + files exist or not. </p> <note> <p>If an attempt to reopen or truncate a log fails (see - <c>reopen</c> and <c>truncate</c>) the disk log process - immediately terminates. Before the process terminates links to - to owners and blocking processes (see <c>block</c>) are removed. - The effect is that the links work in one direction only; any - process using a disk log has to check for the error message - <c>no_such_log</c> if some other process might truncate or - reopen the log simultaneously.</p> + <seealso marker="#reopen/2"><c>reopen/2,3</c></seealso> + and + <seealso marker ="#truncate/1"><c>truncate/1,2</c></seealso>) + the disk log process terminates immediately. Before the process + terminates, links to owners and blocking processes (see + <seealso marker="#block/1"><c>block/1,2</c></seealso>) are removed. + The effect is that the links work in one direction only. Any + process using a disk log must check for error message + <c>no_such_log</c> if some other process truncates or + reopens the log simultaneously.</p> </note> </description> <datatypes> @@ -221,11 +246,10 @@ <funcs> <func> <name name="accessible_logs" arity="0"/> - <fsummary>Return the accessible disk logs on the current node.</fsummary> + <fsummary>Return the accessible disk logs on the current node.</fsummary> <desc> - <p>The <c>accessible_logs/0</c> function returns - the names of the disk logs accessible on the current node. - The first list contains local disk logs, and the + <p>Returns the names of the disk logs accessible on the current node. + The first list contains local disk logs and the second list contains distributed disk logs. </p> </desc> @@ -233,55 +257,55 @@ <func> <name name="alog" arity="2"/> <name name="balog" arity="2"/> - <fsummary>Asynchronously log an item onto a disk log.</fsummary> + <fsummary>Asynchronously log an item on to a disk log.</fsummary> <type variable="Log"/> <type variable="Term" name_i="1"/> <type variable="Bytes"/> <type name="notify_ret"/> <desc> - <p>The <c>alog/2</c> and <c>balog/2</c> functions asynchronously - append an item to a disk log. The function <c>alog/2</c> is - used for internally formatted logs, and the function <c>balog/2</c> - for externally formatted logs. <c>balog/2</c> can be used - for internally formatted logs as well provided the binary was - constructed with a call to <c>term_to_binary/1</c>. + <p>Asynchronously append an item to a disk log. <c>alog/2</c> is + used for internally formatted logs and <c>balog/2</c> + for externally formatted logs. <c>balog/2</c> can also be used + for internally formatted logs if the binary is + constructed with a call to + <seealso marker="erts:erlang#term_to_binary/1"><c>term_to_binary/1</c></seealso>. </p> - <p>The owners that subscribe to notifications will receive the - message <c>read_only</c>, <c>blocked_log</c> - or <c>format_external</c> in case the item cannot be written + <p>Owners subscribing to notifications receive + message <c>read_only</c>, <c>blocked_log</c>, + or <c>format_external</c> if the item cannot be written on the log, and possibly one of the messages <c>wrap</c>, - <c>full</c> and <c>error_status</c> if an item was written - on the log. The message <c>error_status</c> is sent if there - is something wrong with the header function or a file error - occurred. + <c>full</c>, or <c>error_status</c> if an item is written + on the log. Message <c>error_status</c> is sent if + something is wrong with the header function or if a file error + occurs. </p> </desc> </func> <func> <name name="alog_terms" arity="2"/> <name name="balog_terms" arity="2"/> - <fsummary>Asynchronously log several items onto a disk log.</fsummary> + <fsummary>Asynchronously log many items on to a disk log.</fsummary> <type variable="Log"/> <type variable="TermList" name_i="1"/> <type variable="ByteList"/> <type name="notify_ret"/> <desc> - <p>The <c>alog_terms/2</c> and <c>balog_terms/2</c> functions - asynchronously append a list of items to a disk log. - The function <c>alog_terms/2</c> is used for internally - formatted logs, and the function <c>balog_terms/2</c> - for externally formatted logs. <c>balog_terms/2</c> can be used - for internally formatted logs as well provided the binaries were - constructed with calls to <c>term_to_binary/1</c>. + <p>Asynchronously append a list of items to a disk log. + <c>alog_terms/2</c> is used for internally + formatted logs and <c>balog_terms/2</c> + for externally formatted logs. <c>balog_terms/2</c> can also be used + for internally formatted logs if the binaries are + constructed with calls to + <seealso marker="erts:erlang#term_to_binary/1"><c>term_to_binary/1</c></seealso>. </p> - <p>The owners that subscribe to notifications will receive the - message <c>read_only</c>, <c>blocked_log</c> - or <c>format_external</c> in case the items cannot be written + <p>Owners subscribing to notifications receive + message <c>read_only</c>, <c>blocked_log</c>, + or <c>format_external</c> if the items cannot be written on the log, and possibly one or more of the messages <c>wrap</c>, - <c>full</c> and <c>error_status</c> if items were written - on the log. The message <c>error_status</c> is sent if there - is something wrong with the header function or a file error - occurred. + <c>full</c>, and <c>error_status</c> if items are written + on the log. Message <c>error_status</c> is sent if + something is wrong with the header function or if a file error + occurs. </p> </desc> </func> @@ -294,76 +318,75 @@ <p>With a call to <c>block/1,2</c> a process can block a log. If the blocking process is not an owner of the log, a temporary link is created between the disk log process and the blocking - process. The link is used to ensure that the disk log is - unblocked should the blocking process terminate without + process. The link ensures that the disk log is + unblocked if the blocking process terminates without first closing or unblocking the log. </p> <p>Any process can probe a blocked log with <c>info/1</c> or close it with <c>close/1</c>. The blocking process can also - use the functions <c>chunk/2,3</c>, <c>bchunk/2,3</c>, + use functions <c>chunk/2,3</c>, <c>bchunk/2,3</c>, <c>chunk_step/3</c>, and <c>unblock/1</c> without being - affected by the block. Any other attempt than those hitherto - mentioned to update or read a blocked log suspends the - calling process until the log is unblocked or returns an + affected by the block. Any other attempt than those + mentioned so far to update or read a blocked log suspends the + calling process until the log is unblocked or returns error message <c>{blocked_log, <anno>Log</anno>}</c>, depending on whether the value of <c><anno>QueueLogRecords</anno></c> is <c>true</c> - or <c>false</c>. The default value of <c><anno>QueueLogRecords</anno></c> - is <c>true</c>, which is used by <c>block/1</c>. + or <c>false</c>. <c><anno>QueueLogRecords</anno></c> defaults to + <c>true</c>, which is used by <c>block/1</c>. </p> </desc> </func> <func> <name name="change_header" arity="2"/> - <fsummary>Change the head or head_func option for an owner of a disk log.</fsummary> + <fsummary>Change option head or head_func for an owner of a disk log.</fsummary> <desc> - <p>The <c>change_header/2</c> function changes the value of - the <c>head</c> or <c>head_func</c> option of a disk log.</p> + <p>Changes the value of option <c>head</c> or <c>head_func</c> for an owner of a disk log.</p> </desc> </func> <func> <name name="change_notify" arity="3"/> - <fsummary>Change the notify option for an owner of a disk log.</fsummary> + <fsummary>Change option notify for an owner of a disk log.</fsummary> <desc> - <p>The <c>change_notify/3</c> function changes the value of the - <c>notify</c> option for an owner of a disk log. </p> + <p>Changes the value of option <c>notify</c> for an owner of a disk log. </p> </desc> </func> <func> <name name="change_size" arity="2"/> <fsummary>Change the size of an open disk log.</fsummary> <desc> - <p>The <c>change_size/2</c> function changes the size of an open log. - For a halt log it is always possible to increase the size, - but it is not possible to decrease the size to something less than - the current size of the file. + <p>Changes the size of an open log. + For a halt log, the size can always be increased, + but it cannot be decreased to something less than + the current file size. </p> - <p>For a wrap log it is always possible to increase both the - size and number of files, as long as the number of files does not + <p>For a wrap log, both the size and the number of files can always + be increased, as long as the number of files does not exceed 65000. If the maximum number of files is decreased, the - change will not be valid until the current file is full and the + change is not valid until the current file is full and the log wraps to the next file. - The redundant files will be removed next time the log wraps around, - i.e. starts to log to file number 1. + The redundant files are removed the next time the log wraps around, + that is, starts to log to file number 1. </p> <p>As an example, assume that the old maximum number of files is 10 and that the new maximum number of files is 6. If the current file number is not greater than the new maximum number - of files, the files 7 to 10 will be removed when file number 6 + of files, files 7-10 are removed when file 6 is full and the log starts to write to file number 1 again. - Otherwise the files greater than the current - file will be removed when the current file is full (e.g. if - the current file is 8, the files 9 and 10); the files between - new maximum number of files and the current - file (i.e. files 7 and 8) will be removed next time file number 6 + Otherwise, the files greater than the current + file are removed when the current file is full (for example, if + the current file is 8, files 9 and 10 are removed). The files between + the new maximum number of files and the current + file (that is, files 7 and 8) are removed the next time file 6 is full. </p> - <p>If the size of the files is decreased the change will immediately - affect the current log. It will not of course change the - size of log files already full until next time they are used. + <p>If the size of the files is decreased, the change immediately + affects the current log. It does not change the + size of log files already full until the next time they are used. </p> - <p>If the log size is decreased for instance to save space, - the function <c>inc_wrap_file/1</c> can be used to force the log - to wrap. + <p>If the log size is decreased, for example, to save space, + function + <seealso marker="#inc_wrap_file/1"><c>inc_wrap_file/1</c></seealso> + can be used to force the log to wrap. </p> </desc> </func> @@ -380,93 +403,85 @@ <type name="bchunk_ret"/> <type name="chunk_error_rsn"/> <desc> - <p>The <c>chunk/2,3</c> and <c>bchunk/2,3</c> functions make - it possible to efficiently read the terms which have been - appended to an internally formatted log. It minimizes disk - I/O by reading 64 kilobyte chunks from the file. The - <c>bchunk/2,3</c> functions return the binaries read from - the file; they do not call <c>binary_to_term</c>. Otherwise - the work just like <c>chunk/2,3</c>. + <p>Efficiently reads the terms that are appended + to an internally formatted log. It minimizes disk + I/O by reading 64 kilobyte chunks from the file. Functions + <c>bchunk/2,3</c> return the binaries read from + the file, they do not call <c>binary_to_term()</c>. Apart from that, + they work just like <c>chunk/2,3</c>. </p> - <p>The first time <c>chunk</c> (or <c>bchunk</c>) is called, + <p>The first time <c>chunk()</c> (or <c>bchunk()</c>) is called, an initial continuation, the atom <c>start</c>, must be - provided. If there is a disk log process running on the - current node, terms are read from that log, otherwise an + provided. If a disk log process is running on the + current node, terms are read from that log. Otherwise, an individual distributed log on some other node is chosen, if such a log exists. </p> <p>When <c>chunk/3</c> is called, <c><anno>N</anno></c> controls the maximum number of terms that are read from the log in each - chunk. Default is <c>infinity</c>, which means that all the + chunk. Defaults to <c>infinity</c>, which means that all the terms contained in the 64 kilobyte chunk are read. If less than <c><anno>N</anno></c> terms are returned, this does not necessarily mean - that the end of the file has been reached. + that the end of the file is reached. </p> - <p>The <c>chunk</c> function returns a tuple - <c>{<anno>Continuation2</anno>, <anno>Terms</anno>}</c>, where <c><anno>Terms</anno></c> is a list + <p><c>chunk()</c> returns a tuple + <c>{<anno>Continuation2</anno>, <anno>Terms</anno>}</c>, where + <c><anno>Terms</anno></c> is a list of terms found in the log. <c><anno>Continuation2</anno></c> is yet - another continuation which must be passed on to any - subsequent calls to <c>chunk</c>. With a series of calls to - <c>chunk</c> it is possible to extract all terms from a log. + another continuation, which must be passed on to any + subsequent calls to <c>chunk()</c>. With a series of calls to + <c>chunk()</c>, all terms from a log can be extracted. </p> - <p>The <c>chunk</c> function returns a tuple - <c>{<anno>Continuation2</anno>, <anno>Terms</anno>, <anno>Badbytes</anno>}</c> if the log is opened - in read-only mode and the read chunk is corrupt. <c><anno>Badbytes</anno></c> - is the number of bytes in the file which were found not to be - Erlang terms in the chunk. Note also that the log is not repaired. + <p><c>chunk()</c> returns a tuple + <c>{<anno>Continuation2</anno>, <anno>Terms</anno>, <anno>Badbytes</anno>}</c> + if the log is opened in read-only mode and the read chunk is corrupt. + <c><anno>Badbytes</anno></c> is the number of bytes in the file found not to be + Erlang terms in the chunk. Notice that the log is not repaired. When trying to read chunks from a log opened in read-write mode, - the tuple <c>{corrupt_log_file, <anno>FileName</anno>}</c> is returned if the + tuple <c>{corrupt_log_file, <anno>FileName</anno>}</c> is returned if the read chunk is corrupt. </p> - <p><c>chunk</c> returns <c>eof</c> when the end of the log is - reached, or <c>{error, <anno>Reason</anno>}</c> if an error occurs. Should - a wrap log file be missing, a message is output on the error log. + <p><c>chunk()</c> returns <c>eof</c> when the end of the log is + reached, or <c>{error, <anno>Reason</anno>}</c> if an error occurs. If + a wrap log file is missing, a message is output on the error log. </p> <p>When <c>chunk/2,3</c> is used with wrap logs, the returned - continuation may or may not be valid in the next call to - <c>chunk</c>. This is because the log may wrap and delete - the file into which the continuation points. To make sure - this does not happen, the log can be blocked during the - search. + continuation might not be valid in the next call to + <c>chunk()</c>. This is because the log can wrap and delete + the file into which the continuation points. To prevent this, + the log can be blocked during the search. </p> </desc> </func> <func> <name name="chunk_info" arity="1"/> - <fsummary>Return information about a chunk continuation of a disk log.</fsummary> + <fsummary>Return information about a chunk continuation of a disk log.</fsummary> <desc> - <p>The <c>chunk_info/1</c> function returns the following pair + <p>Returns the pair <c>{node, <anno>Node</anno>}</c>, describing the chunk continuation returned by - <c>chunk/2,3</c>, <c>bchunk/2,3</c>, or <c>chunk_step/3</c>: - </p> - <list type="bulleted"> - <item> - <p><c>{node, <anno>Node</anno>}</c>. Terms are read from - the disk log running on <c><anno>Node</anno></c>.</p> - </item> - </list> + <c>chunk/2,3</c>, <c>bchunk/2,3</c>, or <c>chunk_step/3</c>.</p> + <p>Terms are read from the disk log running on <c><anno>Node</anno></c>.</p> </desc> </func> <func> <name name="chunk_step" arity="3"/> - <fsummary>Step forward or backward among the wrap log files of a disk log.</fsummary> + <fsummary>Step forward or backward among the wrap log files of a disk log.</fsummary> <desc> - <p>The function <c>chunk_step</c> can be used in conjunction - with <c>chunk/2,3</c> and <c>bchunk/2,3</c> to search - through an internally formatted wrap log. It takes as + <p>Can be used with <c>chunk/2,3</c> and <c>bchunk/2,3</c> + to search through an internally formatted wrap log. It takes as argument a continuation as returned by <c>chunk/2,3</c>, <c>bchunk/2,3</c>, or <c>chunk_step/3</c>, and steps forward (or backward) <c><anno>Step</anno></c> files in the wrap log. The - continuation returned points to the first log item in the + continuation returned, points to the first log item in the new current file. </p> - <p>If the atom <c>start</c> is given as continuation, a disk log + <p>If atom <c>start</c> is specified as continuation, a disk log to read terms from is chosen. A local or distributed disk log on the current node is preferred to an individual distributed log on some other node. </p> - <p>If the wrap log is not full because all files have not been - used yet, <c>{error, end_of_log}</c> is returned if trying to + <p>If the wrap log is not full because all files are not yet + used, <c>{error, end_of_log}</c> is returned if trying to step outside the log. </p> </desc> @@ -476,21 +491,20 @@ <fsummary>Close a disk log.</fsummary> <type name="close_error_rsn"/> <desc> - <p><marker id="close_1"></marker>The function <c>close/1</c> closes a + <p><marker id="close_1"></marker>Closes a local or distributed disk log properly. An internally formatted log must be closed before the Erlang system is - stopped, otherwise the log is regarded as unclosed and the - automatic repair procedure will be activated next time the + stopped. Otherwise, the log is regarded as unclosed and the + automatic repair procedure is activated next time the log is opened. </p> - <p>The disk log process in not terminated as long as there are - owners or users of the log. It should be stressed that each - and every owner must close the log, possibly by terminating, - and that any other process - not only the processes that have - opened the log anonymously - can decrement the <c>users</c> + <p>The disk log process is not terminated as long as there are + owners or users of the log. All owners must close the log, + possibly by terminating. Also, any other process, not only the processes + that have opened the log anonymously, can decrement the <c>users</c> counter by closing the log. Attempts to close a log by a process that is - not an owner are simply ignored if there are no users. + not an owner are ignored if there are no users. </p> <p>If the log is blocked by the closing process, the log is also unblocked. @@ -499,12 +513,14 @@ </func> <func> <name name="format_error" arity="1"/> - <fsummary>Return an English description of a disk log error reply.</fsummary> + <fsummary>Return an English description of a disk log error reply.</fsummary> <desc> <p>Given the error returned by any function in this module, - the function <c>format_error</c> returns a descriptive string - of the error in English. For file errors, the function - <c>format_error/1</c> in the <c>file</c> module is called.</p> + this function returns a descriptive string + of the error in English. For file errors, function + <c>format_error/1</c> in module + <seealso marker="file#format_error/1"><c>file</c></seealso> + is called.</p> </desc> </func> <func> @@ -513,16 +529,15 @@ <type name="inc_wrap_error_rsn"/> <type name="invalid_header"/> <desc> - <p>The <c>inc_wrap_file/1</c> function forces the internally formatted - disk log to start logging to the - next log file. It can be used, for instance, in conjunction with + <p>Forces the internally formatted disk log to start logging to the + next log file. It can be used, for example, with <c>change_size/2</c> to reduce the amount of disk space allocated by the disk log. </p> - <p>The owners that subscribe to notifications will normally - receive a <c>wrap</c> message, but in case of - an error with a reason tag of <c>invalid_header</c> or - <c>file_error</c> an <c>error_status</c> message will be sent.</p> + <p>Owners subscribing to notifications normally + receive a <c>wrap</c> message, but if + an error occurs with a reason tag of <c>invalid_header</c> or + <c>file_error</c>, an <c>error_status</c> message is sent.</p> </desc> </func> <func> @@ -530,132 +545,148 @@ <fsummary>Return information about a disk log.</fsummary> <type name="dlog_info"/> <desc> - <p>The <c>info/1</c> function returns a list of <c>{Tag, Value}</c> - pairs describing the log. If there is a disk log process running - on the current node, that log is used as source of information, - otherwise an individual distributed log on - some other node is chosen, if such a log exists. + <p>Returns a list of <c>{Tag, Value}</c> pairs describing the log. + If a disk log process is running on the current node, + that log is used as source of information, otherwise an individual + distributed log on some other node is chosen, if such a log exists. </p> <p>The following pairs are returned for all logs: </p> - <list type="bulleted"> + <taglist> + <tag><c>{name, <anno>Log</anno>}</c></tag> <item> - <p><c>{name, <anno>Log</anno>}</c>, where <c><anno>Log</anno></c> is the name of - the log as given by the <c>open/1</c> option <c>name</c>.</p> + <p><c><anno>Log</anno></c> is the log name + as specified by the <c>open/1</c> option <c>name</c>.</p> </item> + <tag><c>{file, <anno>File</anno>}</c></tag> <item> - <p><c>{file, <anno>File</anno>}</c>. For halt logs <c><anno>File</anno></c> is the + <p>For halt logs <c><anno>File</anno></c> is the filename, and for wrap logs <c><anno>File</anno></c> is the base name.</p> </item> + <tag><c>{type, <anno>Type</anno>}</c></tag> <item> - <p><c>{type, <anno>Type</anno>}</c>, where <c><anno>Type</anno></c> is the type of - the log as given by the <c>open/1</c> option <c>type</c>.</p> + <p><c><anno>Type</anno></c> is the log type + as specified by the <c>open/1</c> option <c>type</c>.</p> </item> + <tag><c>{format, <anno>Format</anno>}</c></tag> <item> - <p><c>{format, <anno>Format</anno>}</c>, where <c><anno>Format</anno></c> is the format - of the log as given by the <c>open/1</c> option <c>format</c>.</p> + <p><c><anno>Format</anno></c> is the log format + as specified by the <c>open/1</c> option <c>format</c>.</p> </item> + <tag><c>{size, <anno>Size</anno>}</c></tag> <item> - <p><c>{size, <anno>Size</anno>}</c>, where <c><anno>Size</anno></c> is the size - of the log as given by the <c>open/1</c> option <c>size</c>, + <p><c><anno>Size</anno></c> is the log size + as specified by the <c>open/1</c> option <c>size</c>, or the size set by <c>change_size/2</c>. The value set by <c>change_size/2</c> is reflected immediately.</p> </item> + <tag><c>{mode, <anno>Mode</anno>}</c></tag> <item> - <p><c>{mode, <anno>Mode</anno>}</c>, where <c><anno>Mode</anno></c> is the mode - of the log as given by the <c>open/1</c> option <c>mode</c>.</p> + <p><c><anno>Mode</anno></c> is the log mode + as specified by the <c>open/1</c> option <c>mode</c>.</p> </item> + <tag><c>{owners, [{pid(), <anno>Notify</anno>}]}</c></tag> <item> - <p><c>{owners, [{pid(), <anno>Notify</anno>}]}</c> where <c><anno>Notify</anno></c> + <p><c><anno>Notify</anno></c> is the value set by the <c>open/1</c> option <c>notify</c> - or the function <c>change_notify/3</c> for the owners of + or function <c>change_notify/3</c> for the owners of the log.</p> </item> + <tag><c>{users, <anno>Users</anno>}</c></tag> <item> - <p><c>{users, <anno>Users</anno>}</c> where <c><anno>Users</anno></c> is the number + <p><c><anno>Users</anno></c> is the number of anonymous users of the log, see the <c>open/1</c> option - <seealso marker="#linkto">linkto</seealso>.</p> + <seealso marker="#linkto"><c>linkto</c></seealso>.</p> </item> + <tag><c>{status, <anno>Status</anno>}</c></tag> <item> - <p><c>{status, <anno>Status</anno>}</c>, where <c><anno>Status</anno></c> is <c>ok</c> - or <c>{blocked, <anno>QueueLogRecords</anno>}</c> as set by the functions + <p><c><anno>Status</anno></c> is <c>ok</c> + or <c>{blocked, <anno>QueueLogRecords</anno>}</c> as set by functions <c>block/1,2</c> and <c>unblock/1</c>.</p> </item> + <tag><c>{node, <anno>Node</anno>}</c></tag> <item> - <p><c>{node, <anno>Node</anno>}</c>. The information returned by the - current invocation of the <c>info/1</c> function has been + <p>The information returned by the + current invocation of function <c>info/1</c> is gathered from the disk log process running on <c><anno>Node</anno></c>.</p> </item> + <tag><c>{distributed, <anno>Dist</anno>}</c></tag> <item> - <p><c>{distributed, <anno>Dist</anno>}</c>. If the log is local on - the current node, then <c><anno>Dist</anno></c> has the value <c>local</c>, + <p>If the log is local on + the current node, <c><anno>Dist</anno></c> has the value <c>local</c>, otherwise all nodes where the log is distributed are returned as a list.</p> </item> - </list> + </taglist> <p>The following pairs are returned for all logs opened in <c>read_write</c> mode: </p> - <list type="bulleted"> + <taglist> + <tag><c>{head, <anno>Head</anno>}</c></tag> <item> - <p><c>{head, <anno>Head</anno>}</c>. Depending of the value of - the <c>open/1</c> options <c>head</c> and <c>head_func</c> - or set by the function <c>change_header/2</c>, the value + <p>Depending on the value of + the <c>open/1</c> options <c>head</c> and <c>head_func</c>, + or set by function <c>change_header/2</c>, the value of <c><anno>Head</anno></c> is <c>none</c> (default), - <c>{head, H}</c> (<c>head</c> option) or <c>{M,F,A}</c> + <c>{head, H}</c> (<c>head</c> option), or <c>{M,F,A}</c> (<c>head_func</c> option).</p> </item> + <tag><c>{no_written_items, <anno>NoWrittenItems</anno>}</c></tag> <item> - <p><c>{no_written_items, <anno>NoWrittenItems</anno>}</c>, where - <c><anno>NoWrittenItems</anno></c> is the number of items + <p><c><anno>NoWrittenItems</anno></c> is the number of items written to the log since the disk log process was created.</p> </item> - </list> + </taglist> <p>The following pair is returned for halt logs opened in <c>read_write</c> mode: </p> - <list type="bulleted"> + <taglist> + <tag><c>{full, <anno>Full</anno>}</c></tag> <item> - <p><c>{full, <anno>Full</anno>}</c>, where <c><anno>Full</anno></c> is <c>true</c> or + <p><c><anno>Full</anno></c> is <c>true</c> or <c>false</c> depending on whether the halt log is full or not.</p> </item> - </list> + </taglist> <p>The following pairs are returned for wrap logs opened in <c>read_write</c> mode: </p> - <list type="bulleted"> + <taglist> + <tag><c>{no_current_bytes, integer() >= 0}</c></tag> <item> - <p><c>{no_current_bytes, integer() >= 0}</c> is the number + <p>The number of bytes written to the current wrap log file.</p> </item> + <tag><c>{no_current_items, integer() >= 0}</c></tag> <item> - <p><c>{no_current_items, integer() >= 0}</c> is the number + <p>The number of items written to the current wrap log file, header inclusive.</p> </item> + <tag><c>{no_items, integer() >= 0}</c></tag> <item> - <p><c>{no_items, integer() >= 0}</c> is the total number + <p>The total number of items in all wrap log files.</p> </item> + <tag><c>{current_file, integer()}</c></tag> <item> - <p><c>{current_file, integer()}</c> is the ordinal for + <p>The ordinal for the current wrap log file in the range <c>1..MaxNoFiles</c>, - where <c>MaxNoFiles</c> is given by the <c>open/1</c> option + where <c>MaxNoFiles</c> is specified by the <c>open/1</c> option <c>size</c> or set by <c>change_size/2</c>.</p> </item> + <tag><c>{no_overflows, {<anno>SinceLogWasOpened</anno>, <anno>SinceLastInfo</anno>}}</c></tag> <item> - <p><c>{no_overflows, {<anno>SinceLogWasOpened</anno>, <anno>SinceLastInfo</anno>}}</c>, - where <c><anno>SinceLogWasOpened</anno></c> (<c><anno>SinceLastInfo</anno></c>) is - the number of times a wrap log file has been filled up and a - new one opened or <c>inc_wrap_file/1</c> has been called since + <p><c><anno>SinceLogWasOpened</anno></c> (<c><anno>SinceLastInfo</anno></c>) + is the number of times a wrap log file has been filled up and a + new one is opened or <c>inc_wrap_file/1</c> has been called since the disk log was last opened (<c>info/1</c> was last called). The first time <c>info/2</c> is called after a log was (re)opened or truncated, the two values are equal.</p> </item> - </list> - <p>Note that the <c>chunk/2,3</c>, <c>bchunk/2,3</c>, and - <c>chunk_step/3</c> functions do not affect any value + </taglist> + <p>Notice that functions <c>chunk/2,3</c>, <c>bchunk/2,3</c>, and + <c>chunk_step/3</c> do not affect any value returned by <c>info/1</c>. </p> </desc> @@ -666,17 +697,16 @@ <fsummary>Close a disk log on one node.</fsummary> <type name="lclose_error_rsn"/> <desc> - <p>The function <c>lclose/1</c> closes a local log or an - individual distributed log on the current node. - The function <c>lclose/2</c> closes an individual - distributed log on the specified node if the node - is not the current one. - <c>lclose(<anno>Log</anno>)</c> is equivalent to + <p><c>lclose/1</c> closes a local log or an individual distributed + log on the current node.</p> + <p><c>lclose/2</c> closes an individual distributed log on the + specified node if the node is not the current one.</p> + <p><c>lclose(<anno>Log</anno>)</c> is equivalent to <c>lclose(<anno>Log</anno>, node())</c>. - See also <seealso marker="#close_1">close/1</seealso>. + See also <seealso marker="#close_1"><c>close/1</c></seealso>. </p> - <p>If there is no log with the given name - on the specified node, <c>no_such_log</c> is returned. + <p>If no log with the specified name exist on the specified node, + <c>no_such_log</c> is returned. </p> </desc> </func> @@ -689,25 +719,27 @@ <type variable="Bytes"/> <type name="log_error_rsn"/> <desc> - <p>The <c>log/2</c> and <c>blog/2</c> functions synchronously - append a term to a disk log. They return <c>ok</c> or - <c>{error, <anno>Reason</anno>}</c> when the term has been written to - disk. If the log is distributed, <c>ok</c> is always - returned, unless all nodes are down. Terms are written by - means of the ordinary <c>write()</c> function of the - operating system. Hence, there is no guarantee that the term - has actually been written to the disk, it might linger in - the operating system kernel for a while. To make sure the - item is actually written to disk, the <c>sync/1</c> function + <p>Synchronously + appends a term to a disk log. Returns <c>ok</c> or + <c>{error, <anno>Reason</anno>}</c> when the term is written to + disk. If the log is distributed, <c>ok</c> is returned, + unless all nodes are down. Terms are written by + the ordinary <c>write()</c> function of the + operating system. Hence, it is not guaranteed that the term + is written to disk, it can linger in + the operating system kernel for a while. To ensure that the + item is written to disk, function + <seealso marker="#sync/1"><c>sync/1</c></seealso> must be called. </p> - <p>The <c>log/2</c> function is used for internally formatted logs, + <p><c>log/2</c> is used for internally formatted logs, and <c>blog/2</c> for externally formatted logs. - <c>blog/2</c> can be used - for internally formatted logs as well provided the binary was - constructed with a call to <c>term_to_binary/1</c>. - </p> - <p>The owners that subscribe to notifications will be notified + <c>blog/2</c> can also be used + for internally formatted logs if the binary is + constructed with a call to + <seealso marker="erts:erlang#term_to_binary/1"> + <c>term_to_binary/1</c></seealso>.</p> + <p>Owners subscribing to notifications are notified of an error with an <c>error_status</c> message if the error reason tag is <c>invalid_header</c> or <c>file_error</c>. </p> @@ -716,27 +748,27 @@ <func> <name name="log_terms" arity="2"/> <name name="blog_terms" arity="2"/> - <fsummary>Log several items onto a disk log.</fsummary> + <fsummary>Log many items onto a disk log.</fsummary> <type variable="Log"/> <type variable="TermList" name_i="1"/> <type variable="BytesList"/> <type name="log_error_rsn"/> <desc> - <p>The <c>log_terms/2</c> and <c>blog_terms/2</c> functions - synchronously append a list of items to the log. The benefit - of using these functions rather than the <c>log/2</c> and - <c>blog/2</c> functions is that of efficiency: the given - list is split into as large sublists as possible (limited by - the size of wrap log files), and each sublist is logged as - one single item, which reduces the overhead. + <p>Synchronously appends a list of items to the log. It is more + efficient to use these functions instead of functions <c>log/2</c> + and <c>blog/2</c>. The specified list is split into as large + sublists as possible (limited by the size of wrap log files), + and each sublist is logged as one single item, which reduces + the overhead. </p> - <p>The <c>log_terms/2</c> function is used for internally formatted + <p><c>log_terms/2</c> is used for internally formatted logs, and <c>blog_terms/2</c> for externally formatted logs. - <c>blog_terms/2</c> can be used - for internally formatted logs as well provided the binaries were - constructed with calls to <c>term_to_binary/1</c>. - </p> - <p>The owners that subscribe to notifications will be notified + <c>blog_terms/2</c> can also be used + for internally formatted logs if the binaries are + constructed with calls to + <seealso marker="erts:erlang#term_to_binary/1"> + <c>term_to_binary/1</c></seealso>.</p> + <p>Owners subscribing to notifications are notified of an error with an <c>error_status</c> message if the error reason tag is <c>invalid_header</c> or <c>file_error</c>. </p> @@ -755,110 +787,119 @@ <type name="dlog_optattr"/> <type name="dlog_size"/> <desc> - <p>The <c><anno>ArgL</anno></c> parameter is a list of options which have - the following meanings:</p> - <list type="bulleted"> + <p>Parameter <c><anno>ArgL</anno></c> is a list of the following + options:</p> + <taglist> + <tag><c>{name, <anno>Log</anno>}</c></tag> <item> - <p><c>{name, <anno>Log</anno>}</c> specifies the name of the log. - This is the name which must be passed on as a parameter in + <p>Specifies the log name. + This name must be passed on as a parameter in all subsequent logging operations. A name must always be supplied. </p> </item> + <tag><c>{file, <anno>FileName</anno>}</c></tag> <item> - <p><c>{file, <anno>FileName</anno>}</c> specifies the name of the - file which will be used for logged terms. If this value is - omitted and the name of the log is either an atom or a string, - the file name will default to <c>lists:concat([<anno>Log</anno>, ".LOG"])</c> for halt logs. For wrap logs, this will be - the base name of the files. Each file in a wrap log - will be called <c><![CDATA[<base_name>.N]]></c>, where <c>N</c> is an - integer. Each wrap log will also have two files called + <p>Specifies the name of the + file to be used for logged terms. If this value is + omitted and the log name is an atom or a string, + the filename defaults to <c>lists:concat([<anno>Log</anno>, ".LOG"])</c> + for halt logs.</p> + <p>For wrap logs, this is the base name of the files. Each file in + a wrap log is called <c><![CDATA[<base_name>.N]]></c>, where <c>N</c> + is an integer. Each wrap log also has two files called <c><![CDATA[<base_name>.idx]]></c> and <c><![CDATA[<base_name>.siz]]></c>. </p> </item> + <tag><c>{linkto, <anno>LinkTo</anno>}</c><marker id="linkto"></marker></tag> <item> - <p><c>{linkto, <anno>LinkTo</anno>}</c>. <marker id="linkto"></marker> -If - <c><anno>LinkTo</anno></c> is a pid, that pid becomes an owner of the - log. If <c><anno>LinkTo</anno></c> is <c>none</c> the log records + <p>If <c><anno>LinkTo</anno></c> is a pid, it becomes an owner of the + log. If <c><anno>LinkTo</anno></c> is <c>none</c>, the log records that it is used anonymously by some process by incrementing the <c>users</c> counter. By default, the - process which calls <c>open/1</c> owns the log. + process that calls <c>open/1</c> owns the log. </p> </item> + <tag><c>{repair, <anno>Repair</anno>}</c></tag> <item> - <p><c>{repair, <anno>Repair</anno>}</c>. If <c><anno>Repair</anno></c> is <c>true</c>, - the current log file will be repaired, if needed. As the + <p>If <c><anno>Repair</anno></c> is <c>true</c>, + the current log file is repaired, if needed. As the restoration is initiated, a message is output on the error log. - If <c>false</c> is given, - no automatic repair will be attempted. Instead, the + If <c>false</c> is specified, + no automatic repair is attempted. Instead, the tuple <c>{error, {need_repair, <anno>Log</anno>}}</c> is returned if an attempt is made to open a corrupt log file. - If <c>truncate</c> is given, the log file will - be truncated, creating an empty log. Default is + If <c>truncate</c> is specified, the log file becomes + truncated, creating an empty log. Defaults to <c>true</c>, which has no effect on logs opened in read-only mode. </p> </item> + <tag><c>{type, <anno>Type</anno>}</c></tag> <item> - <p><c>{type, <anno>Type</anno>}</c> is the type of the log. Default - is <c>halt</c>. + <p>The log type. Defaults to <c>halt</c>. </p> </item> + <tag><c>{format, <anno>Format</anno>}</c></tag> <item> - <p><c>{format, <anno>Format</anno>}</c> specifies the format of the - disk log. Default is <c>internal</c>. + <p>Disk log format. Defaults to <c>internal</c>. </p> </item> + <tag><c>{size, <anno>Size</anno>}</c></tag> <item> - <p><c>{size, <anno>Size</anno>}</c> specifies the size of the log. - When a halt log has reached its maximum size, all attempts to - log more items are rejected. The default size is + <p>Log size.</p> + <p>When a halt log has reached its maximum size, all attempts to + log more items are rejected. Defaults to <c>infinity</c>, which for halt implies that there is no - maximum size. For wrap logs, the <c><anno>Size</anno></c> parameter - may be either a pair - <c>{<anno>MaxNoBytes</anno>, <anno>MaxNoFiles</anno>}</c> or <c>infinity</c>. In the - latter case, if the files of an already existing wrap log + maximum size.</p> + <p>For wrap logs, parameter <c><anno>Size</anno></c> + can be a pair + <c>{<anno>MaxNoBytes</anno>, <anno>MaxNoFiles</anno>}</c> or + <c>infinity</c>. + In the latter case, if the files of an existing wrap log with the same name can be found, the size is read - from the existing wrap log, otherwise an error is returned. - Wrap logs write at most <c><anno>MaxNoBytes</anno></c> bytes on each file - and use <c><anno>MaxNoFiles</anno></c> files before starting all over with - the first wrap log file. Regardless of <c><anno>MaxNoBytes</anno></c>, + from the existing wrap log, otherwise an error is returned.</p> + <p>Wrap logs write at most <c><anno>MaxNoBytes</anno></c> + bytes on each file and use <c><anno>MaxNoFiles</anno></c> + files before starting all over with the first wrap log + file. Regardless of <c><anno>MaxNoBytes</anno></c>, at least the header (if there is one) and one - item is written on each wrap log file before - wrapping to the next file. - When opening an existing wrap log, it is not - necessary to supply a value for the option <c>Size</c>, but any - supplied value must equal the current size of the log, otherwise - the tuple <c>{error, {size_mismatch, <anno>CurrentSize</anno>, <anno>NewSize</anno>}}</c> - is returned. - </p> + item are written on each wrap log file before + wrapping to the next file.</p> + <p>When opening an existing wrap log, it is not + necessary to supply a value for option <c>Size</c>, but any + supplied value must equal the current log size, otherwise + the tuple <c>{error, {size_mismatch, <anno>CurrentSize</anno>, + <anno>NewSize</anno>}}</c> is returned.</p> </item> + <tag><c>{distributed, <anno>Nodes</anno>}</c></tag> <item> - <p><c>{distributed, <anno>Nodes</anno>}</c>. This option can be used for - adding members to a distributed disk log. The - default value is <c>[]</c>, which means that + <p>This option can be used for + adding members to a distributed disk log. + Defaults to <c>[]</c>, which means that the log is local on the current node. </p> </item> + <tag><c>{notify, boolean()}</c><marker id="notify"></marker></tag> <item> - <marker id="notify"></marker> - <p><c>{notify, bool()}</c>. If <c>true</c>, the owners of the - log are notified when certain events occur in the log. - Default is <c>false</c>. The owners are sent one of the + <p>If <c>true</c>, the log owners + are notified when certain log events occur. + Defaults to <c>false</c>. The owners are sent one of the following messages when an event occurs: </p> - <list type="bulleted"> + <taglist> + <tag><c>{disk_log, Node, Log, {wrap, NoLostItems}}</c></tag> <item> - <p><c>{disk_log, Node, Log, {wrap, NoLostItems}}</c> is sent when a wrap log has + <p>Sent when a wrap log has filled up one of its files and a new file is opened. <c>NoLostItems</c> is the number of - previously logged items that have been lost when + previously logged items that were lost when truncating existing files. </p> </item> + <tag><c>{disk_log, Node, Log, {truncated, NoLostItems}}</c></tag> <item> - <p><c>{disk_log, Node, Log, {truncated, NoLostItems}}</c> is sent when a log has been + <p>Sent when a log is truncated or reopened. For halt logs <c>NoLostItems</c> is the number of items written on the log since the disk log process was created. For wrap logs @@ -866,127 +907,132 @@ If wrap log files. </p> </item> + <tag><c>{disk_log, Node, Log, {read_only, Items}}</c></tag> <item> - <p><c>{disk_log, Node, Log, {read_only, Items}}</c> - is sent when an asynchronous log attempt is made to + <p>Sent when an asynchronous log attempt is made to a log file opened in read-only mode. <c>Items</c> is the items from the log attempt. </p> </item> + <tag><c>{disk_log, Node, Log, {blocked_log, Items}}</c></tag> <item> - <p><c>{disk_log, Node, Log, {blocked_log, Items}}</c> - is sent when an asynchronous log attempt is made to + <p>Sent when an asynchronous log attempt is made to a blocked log that does not queue log attempts. <c>Items</c> is the items from the log attempt. </p> </item> + <tag><c>{disk_log, Node, Log, {format_external, Items}}</c></tag> <item> - <p><c>{disk_log, Node, Log, {format_external, Items}}</c> - is sent when <c>alog/2</c> or <c>alog_terms/2</c> is + <p>Sent when function <c>alog/2</c> or <c>alog_terms/2</c> is used for internally formatted logs. <c>Items</c> is the items from the log attempt. </p> </item> + <tag><c>{disk_log, Node, Log, full}</c></tag> <item> - <p><c>{disk_log, Node, Log, full}</c> is sent when + <p>Sent when an attempt to log items to a wrap log would write more - bytes than the limit set by the <c>size</c> option. + bytes than the limit set by option <c>size</c>. </p> </item> + <tag><c>{disk_log, Node, Log, {error_status, Status}}</c></tag> <item> - <p><c>{disk_log, Node, Log, {error_status, Status}}</c> - is sent when the error status changes. The error status + <p>Sent when the error status changes. The error status is defined by the outcome of the last attempt to log - items to a the log or to truncate the log or the last - use of <c>sync/1</c>, <c>inc_wrap_file/1</c> or - <c>change_size/2</c>. <c>Status</c> is one of <c>ok</c> and - <c>{error, Error}</c>, the former being the initial value. + items to the log, or to truncate the log, or the last + use of function <c>sync/1</c>, <c>inc_wrap_file/1</c>, or + <c>change_size/2</c>. <c>Status</c> is either <c>ok</c> or + <c>{error, Error}</c>, the former is the initial value. </p> </item> - </list> + </taglist> </item> + <tag><c>{head, <anno>Head</anno>}</c></tag> <item> - <p><c>{head, <anno>Head</anno>}</c> specifies a header to be + <p>Specifies a header to be written first on the log file. If the log is a wrap log, the item <c><anno>Head</anno></c> is written first in each new file. - <c><anno>Head</anno></c> should be a term if the format is - <c>internal</c>, and a deep list of bytes (or a binary) - otherwise. Default is <c>none</c>, which means that + <c><anno>Head</anno></c> is to be a term if the format is + <c>internal</c>, otherwise a deep list of bytes (or a binary). + Defaults to <c>none</c>, which means that no header is written first on the file. </p> </item> + <tag><c>{head_func, {M,F,A}}</c></tag> <item> - <p><c>{head_func, {M,F,A}}</c> specifies a function + <p>Specifies a function to be called each time a new log file is opened. The call <c>M:F(A)</c> is assumed to return <c>{ok, Head}</c>. The item <c>Head</c> is written first in each file. - <c>Head</c> should be a term if the format is - <c>internal</c>, and a deep list of bytes (or a binary) - otherwise. + <c>Head</c> is to be a term if the format is + <c>internal</c>, otherwise a deep list of bytes (or a binary). </p> </item> + <tag><c>{mode, <anno>Mode</anno>}</c></tag> <item> - <p><c>{mode, <anno>Mode</anno>}</c> specifies if the log is to be - opened in read-only or read-write mode. It defaults to + <p>Specifies if the log is to be + opened in read-only or read-write mode. Defaults to <c>read_write</c>. </p> </item> - </list> - <p>The <c>open/1</c> function returns <c>{ok, <anno>Log</anno>}</c> if the - log file was successfully opened. If the file was - successfully repaired, the tuple <c>{repaired, <anno>Log</anno>, {recovered, <anno>Rec</anno>}, {badbytes, <anno>Bad</anno>}}</c> is returned, where - <c><anno>Rec</anno></c> is the number of whole Erlang terms found in the - file and <c><anno>Bad</anno></c> is the number of bytes in the file which - were non-Erlang terms. If the <c>distributed</c> parameter - was given, <c>open/1</c> returns a list of + </taglist> + <p><c>open/1</c> returns <c>{ok, <anno>Log</anno>}</c> if the + log file is successfully opened. If the file is + successfully repaired, the tuple <c>{repaired, <anno>Log</anno>, + {recovered, <anno>Rec</anno>}, {badbytes, <anno>Bad</anno>}}</c> + is returned, where <c><anno>Rec</anno></c> is the number of + whole Erlang terms found in the file and <c><anno>Bad</anno></c> + is the number of bytes in the file that + are non-Erlang terms. If the parameter <c>distributed</c> + is specified, <c>open/1</c> returns a list of successful replies and a list of erroneous replies. Each reply is tagged with the node name. </p> <p>When a disk log is opened in read-write mode, any existing - log file is checked for. If there is none a new empty + log file is checked for. If there is none, a new empty log is created, otherwise the existing file is opened at the position after the last logged item, and the logging of items - will commence from there. If the format is <c>internal</c> + starts from there. If the format is <c>internal</c> and the existing file is not recognized as an internally - formatted log, a tuple <c>{error, {not_a_log_file, <anno>FileName</anno>}}</c> + formatted log, a tuple + <c>{error, {not_a_log_file, <anno>FileName</anno>}}</c> is returned. </p> - <p>The <c>open/1</c> function cannot be used for changing the - values of options of an already open log; when there are prior + <p><c>open/1</c> cannot be used for changing the + values of options of an open log. When there are prior owners or users of a log, all option values except <c>name</c>, - <c>linkto</c> and <c>notify</c> are just checked against - the values that have been supplied before as option values - to <c>open/1</c>, <c>change_header/2</c>, <c>change_notify/3</c> - or <c>change_size/2</c>. As a consequence, + <c>linkto</c>, and <c>notify</c> are only checked against + the values supplied before as option values + to function <c>open/1</c>, <c>change_header/2</c>, <c>change_notify/3</c>, + or <c>change_size/2</c>. Thus, none of the options except <c>name</c> is mandatory. If some - given value differs from the current value, a tuple + specified value differs from the current value, a tuple <c>{error, {arg_mismatch, <anno>OptionName</anno>, <anno>CurrentValue</anno>, <anno>Value</anno>}}</c> - is returned. Caution: an owner's attempt to open a log - as owner once again is acknowledged with the return value + is returned.</p> + <note><p>If an owner attempts to open a log + as owner once again, it is acknowledged with the return value <c>{ok, <anno>Log</anno>}</c>, but the state of the disk log is not - affected in any way. - </p> - <p>If a log with a given name is local on some node, + affected.</p></note> + <p>If a log with a specified name is local on some node, and one tries to open the log distributed on the same node, - then the tuple <c>{error, {node_already_open, <anno>Log</anno>}}</c> is + the tuple <c>{error, {node_already_open, <anno>Log</anno>}}</c> is returned. The same tuple is returned if the log is distributed on some node, and one tries to open the log locally on the same node. Opening individual distributed disk logs for the first time adds those logs to a (possibly empty) distributed disk log. - The option values supplied are used - on all nodes mentioned by the <c>distributed</c> option. + The supplied option values are used + on all nodes mentioned by option <c>distributed</c>. Individual distributed logs know nothing about each other's option values, so each node can be given unique option values by creating a distributed - log with several calls to <c>open/1</c>. + log with many calls to <c>open/1</c>. </p> - <p>It is possible to open a log file more than once by giving - different values to the option <c>name</c> or by using the + <p>A log file can be opened more than once by giving + different values to option <c>name</c> or by using the same file when distributing a log on different nodes. - It is up to the user of the <c>disk_log</c> - module to ensure that no more than one - disk log process has write access to any file, or the - the file may be corrupted. + It is up to the user of module <c>disk_log</c> + to ensure that not more than one disk log process has write + access to any file, otherwise the file can be corrupted. </p> <p>If an attempt to open a log file for the first time fails, the disk log process terminates with the EXIT message @@ -999,9 +1045,9 @@ If <name name="pid2name" arity="1"/> <fsummary>Return the name of the disk log handled by a pid.</fsummary> <desc> - <p>The <c>pid2name/1</c> function returns the name of the log + <p>Returns the log name given the pid of a disk log process on the current node, or - <c>undefined</c> if the given pid is not a disk log process. + <c>undefined</c> if the specified pid is not a disk log process. </p> <p>This function is meant to be used for debugging only. </p> @@ -1018,25 +1064,25 @@ If <type variable="BHead"/> <type name="reopen_error_rsn"/> <desc> - <p>The <c>reopen</c> functions first rename the log file - to <c><anno>File</anno></c> and then re-create a new log file. - In case of a wrap log, <c><anno>File</anno></c> is used as the base name + <p>Renames the log file + to <c><anno>File</anno></c> and then recreates a new log file. + If a wrap log exists, <c><anno>File</anno></c> is used as the base name of the renamed files. By default the header given to <c>open/1</c> is written first in - the newly opened log file, but if the <c><anno>Head</anno></c> or the - <c><anno>BHead</anno></c> argument is given, this item is used instead. - The header argument is used once only; next time a wrap log file + the newly opened log file, but if argument <c><anno>Head</anno></c> or + <c><anno>BHead</anno></c> is specified, this item is used instead. + The header argument is used only once. Next time a wrap log file is opened, the header given to <c>open/1</c> is used. </p> - <p>The <c>reopen/2,3</c> functions are used for internally formatted + <p><c>reopen/2,3</c> are used for internally formatted logs, and <c>breopen/3</c> for externally formatted logs. </p> - <p>The owners that subscribe to notifications will receive + <p>Owners subscribing to notifications receive a <c>truncate</c> message. </p> <p>Upon failure to reopen the log, the disk log process terminates - with the EXIT message <c>{{failed,Error},[{disk_log,Fun,Arity}]}</c>, - and other processes that have requests queued receive the message + with the EXIT message <c>{{failed,Error},[{disk_log,Fun,Arity}]}</c>. + Other processes having requests queued receive the message <c>{disk_log, Node, {error, disk_log_stopped}}</c>. </p> </desc> @@ -1046,8 +1092,7 @@ If <fsummary>Flush the contents of a disk log to the disk.</fsummary> <type name="sync_error_rsn"/> <desc> - <p>The <c>sync/1</c> function ensures that the contents of the - log are actually written to the disk. + <p>Ensures that the contents of the log are written to the disk. This is usually a rather expensive operation. </p> </desc> @@ -1062,24 +1107,24 @@ If <type variable="BHead"/> <type name="trunc_error_rsn"/> <desc> - <p>The <c>truncate</c> functions remove all items from a disk log. - If the <c><anno>Head</anno></c> or the <c><anno>BHead</anno></c> argument is - given, this item is written first in the newly truncated + <p>Removes all items from a disk log. + If argument <c><anno>Head</anno></c> or <c><anno>BHead</anno></c> is + specified, this item is written first in the newly truncated log, otherwise the header given to <c>open/1</c> is used. - The header argument is only used once; next time a wrap log file + The header argument is used only once. Next time a wrap log file is opened, the header given to <c>open/1</c> is used. </p> - <p>The <c>truncate/1,2</c> functions are used for internally + <p><c>truncate/1,2</c> are used for internally formatted logs, and <c>btruncate/2</c> for externally formatted logs. </p> - <p>The owners that subscribe to notifications will receive + <p>Owners subscribing to notifications receive a <c>truncate</c> message. </p> <p>If the attempt to truncate the log fails, the disk log process terminates with the EXIT message - <c>{{failed,Reason},[{disk_log,Fun,Arity}]}</c>, and - other processes that have requests queued receive the message + <c>{{failed,Reason},[{disk_log,Fun,Arity}]}</c>. + Other processes having requests queued receive the message <c>{disk_log, Node, {error, disk_log_stopped}}</c>. </p> </desc> @@ -1089,7 +1134,7 @@ If <fsummary>Unblock a disk log.</fsummary> <type name="unblock_error_rsn"/> <desc> - <p>The <c>unblock/1</c> function unblocks a log. + <p>Unblocks a log. A log can only be unblocked by the blocking process. </p> </desc> @@ -1098,8 +1143,8 @@ If <section> <title>See Also</title> - <p><seealso marker="file">file(3)</seealso>, - <seealso marker="pg2">pg2(3)</seealso>, - <seealso marker="wrap_log_reader">wrap_log_reader(3)</seealso></p> + <p><seealso marker="file"><c>file(3)</c></seealso>, + <seealso marker="pg2"><c>pg2(3)</c></seealso>, + <seealso marker="wrap_log_reader"><c>wrap_log_reader(3)</c></seealso></p> </section> </erlref> diff --git a/lib/kernel/doc/src/erl_boot_server.xml b/lib/kernel/doc/src/erl_boot_server.xml index 60def984ec..897365f9b9 100644 --- a/lib/kernel/doc/src/erl_boot_server.xml +++ b/lib/kernel/doc/src/erl_boot_server.xml @@ -29,72 +29,73 @@ <rev></rev> </header> <module>erl_boot_server</module> - <modulesummary>Boot Server for Other Erlang Machines</modulesummary> + <modulesummary>Boot server for other Erlang machines.</modulesummary> <description> - <p>This server is used to assist diskless Erlang nodes which fetch + <p>This server is used to assist diskless Erlang nodes that fetch all Erlang code from another machine.</p> <p>This server is used to fetch all code, including the start script, if an Erlang runtime system is started with - the <c>-loader inet</c> command line flag. All hosts specified - with the <c>-hosts Host</c> command line flag must have one + command-line flag <c>-loader inet</c>. All hosts specified + with command-line flag <c>-hosts Host</c> must have one instance of this server running.</p> - <p>This server can be started with the <c>kernel</c> configuration + <p>This server can be started with the <c>Kernel</c> configuration parameter <c>start_boot_server</c>.</p> - <p>The <c>erl_boot_server</c> can both read regular files as well as - files in archives. See <seealso marker="code">code(3)</seealso> - and <seealso marker="erts:erl_prim_loader">erl_prim_loader(3)</seealso>.</p> - <warning><p>The support for loading of code from archive files is - experimental. The sole purpose of releasing it before it is ready - is to obtain early feedback. The file format, semantics, - interfaces etc. may be changed in a future release.</p></warning> + <p>The <c>erl_boot_server</c> can read regular files and + files in archives. See <seealso marker="code"><c>code(3)</c></seealso> + and + <seealso marker="erts:erl_prim_loader"><c>erl_prim_loader(3)</c></seealso> + in <c>ERTS</c>.</p> + <warning><p>The support for loading code from archive files is + experimental. It is released before it is ready + to obtain early feedback. The file format, semantics, + interfaces, and so on, can be changed in a future release.</p></warning> </description> <funcs> <func> - <name name="start" arity="1"/> - <fsummary>Start the boot server</fsummary> + <name name="add_slave" arity="1"/> + <fsummary>Add a slave to the list of allowed slaves.</fsummary> <desc> - <p>Starts the boot server. <c><anno>Slaves</anno></c> is a list of IP - addresses for hosts which are allowed to use this server as a - boot server.</p> + <p>Adds a <c><anno>Slave</anno></c> node to the list of allowed slave hosts.</p> </desc> </func> <func> - <name name="start_link" arity="1"/> - <fsummary>Start the boot server and links the caller</fsummary> + <name name="delete_slave" arity="1"/> + <fsummary>Delete a slave from the list of allowed slaves.</fsummary> <desc> - <p>Starts the boot server and links to the caller. This function - is used to start the server if it is included in a supervision - tree.</p> + <p>Deletes a <c><anno>Slave</anno></c> node from the list of allowed slave + hosts.</p> </desc> </func> <func> - <name name="add_slave" arity="1"/> - <fsummary>Add a slave to the list of allowed slaves</fsummary> + <name name="start" arity="1"/> + <fsummary>Start the boot server.</fsummary> <desc> - <p>Adds a <c><anno>Slave</anno></c> node to the list of allowed slave hosts.</p> + <p>Starts the boot server. <c><anno>Slaves</anno></c> is a list of + IP addresses for hosts, which are allowed to use this server as a + boot server.</p> </desc> </func> <func> - <name name="delete_slave" arity="1"/> - <fsummary>Delete a slave from the list of allowed slaves</fsummary> + <name name="start_link" arity="1"/> + <fsummary>Start the boot server and link to the the caller.</fsummary> <desc> - <p>Deletes a <c><anno>Slave</anno></c> node from the list of allowed slave - hosts.</p> + <p>Starts the boot server and links to the caller. This function + is used to start the server if it is included in a supervision + tree.</p> </desc> </func> <func> <name name="which_slaves" arity="0"/> - <fsummary>Return the current list of allowed slave hosts</fsummary> + <fsummary>Return the current list of allowed slave hosts.</fsummary> <desc> <p>Returns the current list of allowed slave hosts.</p> </desc> </func> </funcs> - <section> <title>SEE ALSO</title> - <p><seealso marker="erts:init">init(3)</seealso>, - <seealso marker="erts:erl_prim_loader">erl_prim_loader(3)</seealso></p> + <p><seealso marker="erts:init"><c>erts:init(3)</c></seealso>, + <seealso marker="erts:erl_prim_loader"><c>erts:erl_prim_loader(3)</c></seealso></p> </section> </erlref> diff --git a/lib/kernel/doc/src/erl_ddll.xml b/lib/kernel/doc/src/erl_ddll.xml index 6421a30dcf..a5ce58ef3e 100644 --- a/lib/kernel/doc/src/erl_ddll.xml +++ b/lib/kernel/doc/src/erl_ddll.xml @@ -29,84 +29,91 @@ <rev></rev> </header> <module>erl_ddll</module> - <modulesummary>Dynamic Driver Loader and Linker</modulesummary> + <modulesummary>Dynamic driver loader and linker.</modulesummary> <description> - <p>The <c>erl_ddll</c> module provides an interface for loading - and unloading <em>erlang linked in drivers</em> in runtime.</p> + <p>This module provides an interface for loading + and unloading <em>Erlang linked-in drivers</em> in runtime.</p> <note> - <p>This is a large reference document. For casual use of the - module, as well as for most real world applications, the - descriptions of the functions <seealso marker="#load/2">load/2</seealso> and <seealso marker="#unload/1">unload/1</seealso> are enough to get - going. </p> + <p>This is a large reference document. For casual use of this + module, and for most real world applications, the + descriptions of functions + <seealso marker="#load/2"><c>load/2</c></seealso> and + <seealso marker="#unload/1"><c>unload/1</c></seealso> + are enough to getting started.</p> </note> - <p>The driver should be provided as a dynamically linked library - in a object code format specific for the platform in use, - i. e. <c>.so</c> files on most Unix systems and <c>.ddl</c> - files on windows. An erlang linked in driver has to provide + <p>The driver is to be provided as a dynamically linked library + in an object code format specific for the platform in use, + that is, <c>.so</c> files on most Unix systems and <c>.ddl</c> + files on Windows. An Erlang linked-in driver must provide specific interfaces to the emulator, so this module is not - designed for loading arbitrary dynamic libraries. For further - information about erlang drivers, refer to the ERTS reference - manual section <seealso marker="erts:erl_driver">erl_driver</seealso>.</p> + designed for loading arbitrary dynamic libraries. For more + information about Erlang drivers, see + <seealso marker="erts:erl_driver"><c>erts:erl_driver</c></seealso> + .</p> <marker id="users"></marker> - <p>When describing a set of functions, (i.e. a module, a part of a - module or an application) executing in a process and wanting to - use a ddll-driver, we use the term <em>user</em>. There can be - several users in one process (different modules needing the same - driver) and several processes running the same code, making up - several <em>users</em> of a driver. In the basic scenario, each - user loads the driver before starting to use it and unloads the - driver when done. The reference counting keeps track of - processes as well as the number of loads by each process, so that - the driver will only be unloaded when no one wants it - (it has no user). The driver also keeps track of ports that are - opened towards it, so that one can delay unloading until all - ports are closed or kill all ports using the driver when it is - unloaded. </p> + <p>When describing a set of functions (that is, a module, a part of a + module, or an application), executing in a process and wanting to + use a ddll-driver, we use the term <em>user</em>. A process can + have many users (different modules needing the same + driver) and many processes running the same code, making up + many <em>users</em> of a driver.</p> + <p>In the basic scenario, each user loads the driver before + starting to use it and unloads the driver when done. + The reference counting keeps track of + processes and the number of loads by each process. This way + the driver is only unloaded when no one wants it (it has no user). + The driver also keeps track of ports that are + opened to it. This enables delay of unloading until all + ports are closed, or killing of all ports that use the driver when + it is unloaded.</p> <marker id="scenarios"></marker> <p>The interface supports two basic scenarios of loading and unloading. Each scenario can also have the option of either killing ports when the driver is unloading, or waiting for the - ports to close themselves. The scenarios are:</p> + ports to close themselves. The scenarios are as follows:</p> <taglist> - <tag><em>Load and unload on a "when needed basis"</em></tag> + <tag><em>Load and Unload on a "When Needed Basis"</em></tag> <item> <p>This (most common) scenario simply supports that each <seealso marker="#users">user</seealso> of the driver loads - it when it is needed and unloads it when the <seealso marker="#users">user</seealso> no longer have any use for - it. The driver is always reference counted and as long as a + it when needed and unloads it when no longer needed. + The driver is always reference counted and as long as a process keeping the driver loaded is still alive, the driver is present in the system.</p> <p>Each <seealso marker="#users">user</seealso> of the driver use <em>literally</em> the same pathname for the driver when - demanding load, but the <seealso marker="#users">users</seealso> are not really concerned - with if the driver is already loaded from the filesystem or - if the object code has to be loaded from filesystem.</p> - <p>Two pairs of functions support this scenario:</p> + demanding load, but the + <seealso marker="#users">users</seealso> are not concerned + with if the driver is already loaded from the file system or + if the object code must be loaded from file system.</p> + <p>The following two pairs of functions support this scenario:</p> <taglist> <tag><em>load/2 and unload/1</em></tag> <item> <p>When using the <c>load/unload</c> interfaces, the - driver will not <em>actually</em> get unloaded until the - <em>last port</em> using the driver is closed. The function - <c>unload/1</c> can return immediately, as the <seealso marker="#users">users</seealso> are not really concerned - with when the actual unloading occurs. The - driver will actually get unloaded when no one needs it any longer.</p> - <p>If a process having the driver loaded dies, it will have - the same effect as if unloading was done. </p> - <p>When loading, the function <c>load/2</c> returns - <c>ok</c> as soon as there is any instance of the driver - present, so that if a driver is waiting to get unloaded - (due to open ports), it will simply change state to no + driver is not unloaded until the + <em>last port</em> using the driver is closed. Function + <c>unload/1</c> can return immediately, as the + <seealso marker="#users">users</seealso> + have no interrest in when the unloading occurs. The + driver is unloaded when no one needs it any longer.</p> + <p>If a process having the driver loaded dies, it has + the same effect as if unloading is done.</p> + <p>When loading, function <c>load/2</c> returns + <c>ok</c> when any instance of the driver is + present. Thus, if a driver is waiting to get unloaded + (because of open ports), it simply changes state to no longer need unloading.</p> </item> <tag><em>load_driver/2 and unload_driver/1</em></tag> <item> - <p>These interfaces is intended to be used when it is considered an - error that ports are open towards a driver that no <seealso marker="#users">user</seealso> - has loaded. The ports still open when the + <p>These interfaces are intended to be used when it is considered an + error that ports are open to a driver that no + <seealso marker="#users">user</seealso> + has loaded. The ports that are still open when the last <seealso marker="#users">user</seealso> calls <c>unload_driver/1</c> or when the last process having the - driver loaded dies, will get killed with reason + driver loaded dies, are killed with reason <c>driver_unloaded</c>.</p> <p>The function names <c>load_driver</c> and <c>unload_driver</c> are kept for backward @@ -114,60 +121,66 @@ </item> </taglist> </item> - <tag><em>Loading and reloading for code replacement</em></tag> + <tag><em>Loading and Reloading for Code Replacement</em></tag> <item> - <p>This scenario occurs when the driver code might need + <p>This scenario can occur if the driver code needs replacement during operation of the Erlang - emulator. Implementing driver code replacement is somewhat - more tedious than beam code replacement, as one driver - cannot be loaded as both "old" and "new" code. All <seealso marker="#users">users</seealso> of a driver must have it + emulator. Implementing driver code replacement is a little + more tedious than Beam code replacement, as one driver + cannot be loaded as both "old" and "new" code. All + <seealso marker="#users">users</seealso> of a driver must have it closed (no open ports) before the old code can be unloaded and the new code can be loaded.</p> - <p>The actual unloading/loading is done as one atomic + <p>The unloading/loading is done as one atomic operation, blocking all processes in the system from using - the driver concerned while in progress.</p> + the driver in question while in progress.</p> <p>The preferred way to do driver code replacement is to let <em>one single process</em> keep track of the driver. When - the process start, the driver is loaded. When replacement + the process starts, the driver is loaded. When replacement is required, the driver is reloaded. Unload is probably never - done, or done when the process exits. If more than one <seealso marker="#users">user</seealso> has a driver loaded when code - replacement is demanded, the replacement cannot occur until - the last "other" <seealso marker="#users">user</seealso> has + done, or done when the process exits. If more than one + <seealso marker="#users">user</seealso> has a driver + loaded when code replacement is demanded, the replacement cannot + occur until the last "other" + <seealso marker="#users">user</seealso> has unloaded the driver.</p> <p>Demanding reload when a reload is already in progress is - always an error. Using the high level functions, it is also - an error to demand reloading when more than one <seealso marker="#users">user</seealso> has the driver loaded. To - simplify driver replacement, avoid designing your system so - that more than than one <seealso marker="#users">user</seealso> has the driver loaded.</p> - <p>The two functions for reloading drivers should be used - together with corresponding load functions, to support the two + always an error. Using the high-level functions, it is also + an error to demand reloading when more than one + <seealso marker="#users">user</seealso> has the driver loaded.</p> + <p>To simplify driver replacement, avoid designing your system so + that more than one + <seealso marker="#users">user</seealso> has the driver loaded.</p> + <p>The two functions for reloading drivers are to be used + together with corresponding load functions to support the two different behaviors concerning open ports:</p> <taglist> <tag><em>load/2 and reload/2</em></tag> <item> - <p>This pair of functions is used when reloading should be - done after the last open port towards the driver is + <p>This pair of functions is used when reloading is to be + done after the last open port to the driver is closed.</p> - <p>As <c>reload/2</c> actually waits for the reloading to - occur, a misbehaving process keeping open ports towards - the driver (or keeping the driver loaded) might cause - infinite waiting for reload. Timeouts has to be provided + <p>As <c>reload/2</c> waits for the reloading to + occur, a misbehaving process keeping open ports to + the driver (or keeping the driver loaded) can cause + infinite waiting for reload. Time-outs must be provided outside of the process demanding the reload or by using - the low-level interface <seealso marker="#try_load/3">try_load/3</seealso> in combination - with driver monitors (see below).</p> + the low-level interface + <seealso marker="#try_load/3"><c>try_load/3</c></seealso> + in combination with driver monitors.</p> </item> <tag><em>load_driver/2 and reload_driver/2</em></tag> <item> - <p>This pair of functions are used when open ports towards - the driver should be killed with reason + <p>This pair of functions are used when open ports to + the driver are to be killed with reason <c>driver_unloaded</c> to allow for new driver code to get loaded.</p> - <p>If, however, another process has the driver loaded, - calling <c>reload_driver</c> returns the error code + <p>However, if another process has the driver loaded, + calling <c>reload_driver</c> returns error code <c>pending_process</c>. As stated earlier, - the recommended design is to not allow other <seealso marker="#users">users</seealso> than the "driver - reloader" to actually demand loading of the concerned - driver.</p> + the recommended design is to not allow other + <seealso marker="#users">users</seealso> than the "driver + reloader" to demand loading of the driver in question.</p> </item> </taglist> </item> @@ -184,903 +197,982 @@ <funcs> <func> <name name="demonitor" arity="1"/> - <fsummary>Remove a monitor for a driver</fsummary> + <fsummary>Remove a monitor for a driver.</fsummary> <desc> <p>Removes a driver monitor in much the same way as - <seealso marker="erts:erlang#erlang:demonitor/1">erlang:demonitor/1</seealso> does with process - monitors. See <seealso marker="#monitor/2">monitor/2</seealso>, <seealso marker="#try_load/3">try_load/3</seealso> and <seealso marker="#try_unload/2">try_unload/2</seealso> for details - about how to create driver monitors.</p> + <seealso marker="erts:erlang#erlang:demonitor/1"><c>erlang:demonitor/1</c></seealso> + in <c>ERTS</c> + does with process monitors. For details about how to create + driver monitors, see + <seealso marker="#monitor/2"><c>monitor/2</c></seealso>, + <seealso marker="#try_load/3"><c>try_load/3</c></seealso>, and + <seealso marker="#try_unload/2"><c>try_unload/2</c></seealso>.</p> <p>The function throws a <c>badarg</c> exception if the - parameter is not a reference(). </p> + parameter is not a <c>reference()</c>.</p> + </desc> + </func> + <func> + <name name="format_error" arity="1"/> + <fsummary>Format an error descriptor.</fsummary> + <desc> + <p>Takes an <c><anno>ErrorDesc</anno></c> returned by load, unload, or + reload functions and returns a string that + describes the error or warning.</p> + <note> + <p>Because of peculiarities in the dynamic loading interfaces on + different platforms, the returned string is only guaranteed + to describe the correct error <em>if format_error/1 is called + in the same instance of the Erlang virtual machine as the error + appeared in</em> (meaning the same operating + system process).</p> + </note> </desc> </func> <func> <name name="info" arity="0"/> - <fsummary>Retrieve information about all drivers</fsummary> + <fsummary>Retrieve information about all drivers.</fsummary> <desc> - <p>Returns a list of tuples <c>{<anno>DriverName</anno>, <anno>InfoList</anno>}</c>, where - <c><anno>InfoList</anno></c> is the result of calling <seealso marker="#info/1">info/1</seealso> for that - <c><anno>DriverName</anno></c>. Only dynamically linked in drivers are + <p>Returns a list of tuples <c>{<anno>DriverName</anno>, <anno>InfoList</anno>}</c>, + where <c><anno>InfoList</anno></c> is the result of calling + <seealso marker="#info/1"><c>info/1</c></seealso> for that + <c><anno>DriverName</anno></c>. Only dynamically linked-in drivers are included in the list.</p> </desc> </func> <func> <name name="info" arity="1"/> - <fsummary>Retrieve information about one driver</fsummary> + <fsummary>Retrieve information about one driver.</fsummary> <desc> - <p>Returns a list of tuples <c>{<anno>Tag</anno>, <anno>Value</anno>}</c>, where - <c><anno>Tag</anno></c> is the information item and <c><anno>Value</anno></c> is the result - of calling <seealso marker="#info/2">info/2</seealso> with this driver name and - this tag. The result being a tuple list containing all - information available about a driver. </p> - <p>The different tags that will appear in the list are:</p> + <p>Returns a list of tuples <c>{<anno>Tag</anno>, <anno>Value</anno>}</c>, + where <c><anno>Tag</anno></c> is the information item and + <c><anno>Value</anno></c> is the result of calling + <seealso marker="#info/2"><c>info/2</c></seealso> with this driver + name and this tag. The result is a tuple list containing all information + available about a driver.</p> + <p>The following tags appears in the list:</p> <list type="bulleted"> - <item>processes</item> - <item>driver_options</item> - <item>port_count</item> - <item>linked_in_driver</item> - <item>permanent</item> - <item>awaiting_load</item> - <item>awaiting_unload</item> + <item><c>processes</c></item> + <item><c>driver_options</c></item> + <item><c>port_count</c></item> + <item><c>linked_in_driver</c></item> + <item><c>permanent</c></item> + <item><c>awaiting_load</c></item> + <item><c>awaiting_unload</c></item> </list> - <p>For a detailed description of each value, please read the - description of <seealso marker="#info/2">info/2</seealso> below.</p> + <p>For a detailed description of each value, see + <seealso marker="#info/2"><c>info/2</c></seealso>.</p> <p>The function throws a <c>badarg</c> exception if the driver is not present in the system.</p> </desc> </func> <func> <name name="info" arity="2"/> - <fsummary>Retrieve specific information about one driver</fsummary> + <fsummary>Retrieve specific information about one driver.</fsummary> <desc> - <p>This function returns specific information about one aspect - of a driver. The <c><anno>Tag</anno></c> parameter specifies which aspect - to get information about. The <c><anno>Value</anno></c> return differs + <p>Returns specific information about one aspect of a driver. + Parameter <c><anno>Tag</anno></c> specifies which aspect + to get information about. The return <c><anno>Value</anno></c> differs between different tags:</p> <taglist> - <tag><em>processes</em></tag> + <tag><c>processes</c></tag> <item> - <p>Return all processes containing <seealso marker="#users">users</seealso> of the specific drivers - as a list of tuples <c>{pid(),integer() >= 0}</c>, where the - <c>integer()</c> denotes the number of users in the process + <p>Returns all processes containing + <seealso marker="#users">users</seealso> of the specific drivers + as a list of tuples <c>{pid(),integer() >= 0}</c>, where + <c>integer()</c> denotes the number of users in process <c>pid()</c>.</p> </item> - <tag><em>driver_options</em></tag> + <tag><c>driver_options</c></tag> <item> - <p>Return a list of the driver options provided when - loading, as well as any options set by the driver itself - during initialization. The currently only valid option - being <c>kill_ports</c>.</p> + <p>Returns a list of the driver options provided when + loading, and any options set by the driver + during initialization. The only valid option + is <c>kill_ports</c>.</p> </item> - <tag><em>port_count</em></tag> + <tag><c>port_count</c></tag> <item> - <p>Return the number of ports (an <c>integer >= 0()</c>) using the driver.</p> + <p>Returns the number of ports (an <c>integer() >= 0</c>) + using the driver.</p> </item> - <tag><em>linked_in_driver</em></tag> + <tag><c>linked_in_driver</c></tag> <item> - <p>Return a <c>boolean()</c>, being <c>true</c> if the driver is a - statically linked in one and <c>false</c> otherwise.</p> + <p>Returns a <c>boolean()</c>, which is <c>true</c> if the driver is a + statically linked-in one, otherwise <c>false</c>.</p> </item> - <tag><em>permanent</em></tag> + <tag><c>permanent</c></tag> <item> - <p>Return a <c>boolean()</c>, being <c>true</c> if the driver has made - itself permanent (and is <em>not</em> a statically - linked in driver). <c>false</c> otherwise.</p> + <p>Returns a <c>boolean()</c>, which is <c>true</c> if the driver has + made itself permanent (and is <em>not</em> a statically + linked-in driver), otherwise <c>false</c>.</p> </item> - <tag><em>awaiting_load</em></tag> + <tag><c>awaiting_load</c></tag> <item> - <p>Return a list of all processes having monitors for - <c>loading</c> active, each process returned as - <c>{pid(),integer() >= 0}</c>, where the <c>integer()</c> is the - number of monitors held by the process <c>pid()</c>.</p> + <p>Returns a list of all processes having monitors for + <c>loading</c> active. Each process is returned as + <c>{pid(),integer() >= 0}</c>, where <c>integer()</c> is the + number of monitors held by process <c>pid()</c>.</p> </item> - <tag><em>awaiting_unload</em></tag> + <tag><c>awaiting_unload</c></tag> <item> - <p>Return a list of all processes having monitors for - <c>unloading</c> active, each process returned as - <c>{pid(),integer() >= 0}</c>, where the <c>integer()</c> is the - number of monitors held by the process <c>pid()</c>.</p> + <p>Returns a list of all processes having monitors for + <c>unloading</c> active. Each process is returned as + <c>{pid(),integer() >= 0}</c>, where <c>integer()</c> is the + number of monitors held by process <c>pid()</c>.</p> </item> </taglist> - <p>If the options <c>linked_in_driver</c> or <c>permanent</c> - return true, all other options will return the value - <c>linked_in_driver</c> or <c>permanent</c> respectively.</p> + <p>If option <c>linked_in_driver</c> or <c>permanent</c> + returns <c>true</c>, all other options return + <c>linked_in_driver</c> or <c>permanent</c>, respectively.</p> <p>The function throws a <c>badarg</c> exception if the driver - is not present in the system or the tag is not supported.</p> + is not present in the system or if the tag is not supported.</p> </desc> </func> <func> <name name="load" arity="2"/> - <fsummary>Load a driver</fsummary> + <fsummary>Load a driver.</fsummary> <desc> - <p>Loads and links the dynamic driver <c><anno>Name</anno></c>. <c><anno>Path</anno></c> + <p>Loads and links the dynamic driver <c><anno>Name</anno></c>. + <c><anno>Path</anno></c> is a file path to the directory containing the driver. <c><anno>Name</anno></c> must be a sharable object/dynamic library. Two drivers with different <c><anno>Path</anno></c> parameters cannot be - loaded under the same name. The <c><anno>Name</anno></c> is a string or + loaded under the same name. <c><anno>Name</anno></c> is a string or atom containing at least one character.</p> - <p>The <c><anno>Name</anno></c> given should correspond to the filename - of the actual dynamically loadable object file residing in - the directory given as <c><anno>Path</anno></c>, but <em>without</em> the - extension (i.e. <c>.so</c>). The driver name provided in + <p>The <c><anno>Name</anno></c> specified is to correspond to the filename + of the dynamically loadable object file residing in + the directory specified as <c><anno>Path</anno></c>, but <em>without</em> the + extension (that is, <c>.so</c>). The driver name provided in the driver initialization routine must correspond with the - filename, in much the same way as erlang module names + filename, in much the same way as Erlang module names correspond to the names of the <c>.beam</c> files.</p> - <p>If the driver has been previously unloaded, but is still - present due to open ports against it, a call to - <c>load/2</c> will stop the unloading and keep the driver - (as long as the <c><anno>Path</anno></c> is the same) and <c>ok</c> is - returned. If one actually wants the object code to be - reloaded, one uses <seealso marker="#reload/2">reload/2</seealso> or the low-level - interface <seealso marker="#try_load/3">try_load/3</seealso> - instead. Please refer to the description of <seealso marker="#scenarios">different scenarios</seealso> for + <p>If the driver was previously unloaded, but is still + present because of open ports to it, a call to + <c>load/2</c> stops the unloading and keeps the driver + (as long as <c><anno>Path</anno></c> is the same), and <c>ok</c> is + returned. If you really want the object code to be + reloaded, use <seealso marker="#reload/2"><c>reload/2</c></seealso> + or the low-level interface + <seealso marker="#try_load/3"><c>try_load/3</c></seealso> instead. + See also the description of + <seealso marker="#scenarios"><c>different scenarios</c></seealso> for loading/unloading in the introduction.</p> <p>If more than one process tries to load an already loaded - driver withe the same <c><anno>Path</anno></c>, or if the same process - tries to load it several times, the function will return - <c>ok</c>. The emulator will keep track of the + driver with the same <c><anno>Path</anno></c>, or if the same process + tries to load it many times, the function returns + <c>ok</c>. The emulator keeps track of the <c>load/2</c> calls, so that a corresponding number of - <c>unload/2</c> calls will have to be done from the same - process before the driver will actually get unloaded. It is + <c>unload/2</c> calls must be done from the same + process before the driver gets unloaded. It is therefore safe for an application to load a driver that is shared between processes or applications when needed. It can safely be unloaded without causing trouble for other - parts of the system. </p> - <p>It is not allowed to load - several drivers with the same name but with different - <c>Path</c> parameters.</p> + parts of the system.</p> + <p>It is not allowed to load multiple drivers with + the same name but with different <c>Path</c> parameters.</p> <note> - <p>Note especially that the <c><anno>Path</anno></c> is interpreted - literally, so that all loaders of the same driver needs to - give the same <em>literal</em><c><anno>Path</anno></c> string, even - though different paths might point out the same directory - in the filesystem (due to use of relative paths and + <p><c><anno>Path</anno></c> is interpreted + literally, so that all loaders of the same driver must + specify the same <em>literal</em> <c><anno>Path</anno></c> string, + although different paths can point out the same directory + in the file system (because of use of relative paths and links).</p> </note> <p>On success, the function returns <c>ok</c>. On failure, the return value is <c>{error,<anno>ErrorDesc</anno>}</c>, where <c><anno>ErrorDesc</anno></c> is an opaque term to be - translated into human readable form by the <seealso marker="#format_error/1">format_error/1</seealso> - function.</p> - <p>For more control over the error handling, again use the - <seealso marker="#try_load/3">try_load/3</seealso> + translated into human readable form by function + <seealso marker="#format_error/1"><c>format_error/1</c></seealso>.</p> + <p>For more control over the error handling, use the + <seealso marker="#try_load/3"><c>try_load/3</c></seealso> interface instead.</p> <p>The function throws a <c>badarg</c> exception if the - parameters are not given as described above. </p> + parameters are not specified as described here.</p> </desc> </func> <func> <name name="load_driver" arity="2"/> - <fsummary>Load a driver</fsummary> + <fsummary>Load a driver.</fsummary> <desc> - <p>Works essentially as <c>load/2</c>, but will load the driver - with other options. All ports that are using the - driver will get killed with the reason - <c>driver_unloaded</c> when the driver is to be unloaded.</p> - <p>The number of loads and unloads by different <seealso marker="#users">users</seealso> influence the actual loading - and unloading of a driver file. The port killing will - therefore only happen when the <em>last</em> <seealso marker="#users">user</seealso> unloads the driver, or the - last process having loaded the driver exits.</p> + <p>Works essentially as <c>load/2</c>, but loads the driver + with other options. All ports using the + driver are killed with reason <c>driver_unloaded</c> + when the driver is to be unloaded.</p> + <p>The number of loads and unloads by different + <seealso marker="#users">users</seealso> influences the loading + and unloading of a driver file. The port killing + therefore only occurs when the <em>last</em> + <seealso marker="#users">user</seealso> unloads the driver, + or when the last process having loaded the driver exits.</p> <p>This interface (or at least the name of the functions) is - kept for backward compatibility. Using <seealso marker="#try_load/3">try_load/3</seealso> with - <c>{driver_options,[kill_ports]} </c> in the option list will - give the same effect regarding the port killing.</p> + kept for backward compatibility. + Using <seealso marker="#try_load/3"><c>try_load/3</c></seealso> with + <c>{driver_options,[kill_ports]}</c> in the option list + gives the same effect regarding the port killing.</p> <p>The function throws a <c>badarg</c> exception if the - parameters are not given as described above. </p> + parameters are not specified as described here.</p> + </desc> + </func> + <func> + <name name="loaded_drivers" arity="0"/> + <fsummary>List loaded drivers.</fsummary> + <desc> + <p>Returns a list of all the available drivers, both + (statically) linked-in and dynamically loaded ones.</p> + <p>The driver names are returned as a list of strings rather + than a list of atoms for historical reasons.</p> + <p>For more information about drivers, see + <seealso marker="#info/0"><c>info</c></seealso>.</p> </desc> </func> <func> <name name="monitor" arity="2"/> - <fsummary>Create a monitor for a driver</fsummary> + <fsummary>Create a monitor for a driver.</fsummary> <desc> - <p>This function creates a driver monitor and works in many - ways as the function <seealso marker="erts:erlang#erlang:monitor/2">erlang:monitor/2</seealso>, + <p>Creates a driver monitor and works in many + ways as + <seealso marker="erts:erlang#erlang:monitor/2"><c>erlang:monitor/2</c></seealso> + in <c>ERTS</c>, does for processes. When a driver changes state, the monitor - results in a monitor-message being sent to the calling - process. The <c><anno>MonitorRef</anno></c> returned by this function is + results in a monitor message that is sent to the calling + process. <c><anno>MonitorRef</anno></c> returned by this function is included in the message sent.</p> - <p>As with process monitors, each driver monitor set will only - generate <em>one single message</em>. The monitor is - "destroyed" after the message is sent and there is then no - need to call <seealso marker="#demonitor/1">demonitor/1</seealso>.</p> - <p>The <c><anno>MonitorRef</anno></c> can also be used in subsequent calls - to <seealso marker="#demonitor/1">demonitor/1</seealso> to + <p>As with process monitors, each driver monitor set only + generates <em>one single message</em>. The monitor is + "destroyed" after the message is sent, so it is then not + needed to call + <seealso marker="#demonitor/1"><c>demonitor/1</c></seealso>.</p> + <p><c><anno>MonitorRef</anno></c> can also be used in subsequent calls + to <seealso marker="#demonitor/1"><c>demonitor/1</c></seealso> to remove a monitor.</p> <p>The function accepts the following parameters:</p> <taglist> - <tag><em><c><anno>Tag</anno></c></em></tag> + <tag><c><anno>Tag</anno></c></tag> <item> - <p>The monitor tag is always <c>driver</c> as this function + <p>The monitor tag is always <c>driver</c>, as this function can only be used to create driver monitors. In the future, driver monitors will be integrated with process monitors, - why this parameter has to be given for consistence.</p> + why this parameter has to be specified for consistence.</p> </item> - <tag><em><c><anno>Item</anno></c></em></tag> + <tag><c><anno>Item</anno></c></tag> <item> - <p>The <c><anno>Item</anno></c> parameter specifies which driver one - wants to monitor (the name of the driver) as well as - which state change one wants to monitor. The parameter + <p>Parameter <c><anno>Item</anno></c> specifies + which driver to monitor (the driver name) and + which state change to monitor. The parameter is a tuple of arity two whose first element is the - driver name and second element is either of:</p> + driver name and second element is one of the following:</p> <taglist> - <tag><em>loaded</em></tag> + <tag><c>loaded</c></tag> <item> - <p>Notify me when the driver is reloaded (or loaded if + <p>Notifies when the driver is reloaded (or loaded if loading is underway). It only makes sense to monitor drivers that are in the process of being loaded or - reloaded. One cannot monitor a future-to-be driver - name for loading, that will only result in a - <c>'DOWN'</c> message being immediately sent. + reloaded. A future driver name for loading cannot be + monitored. That only results in a + <c>DOWN</c> message sent immediately. Monitoring for loading is therefore most useful when - triggered by the <seealso marker="#try_load/3">try_load/3</seealso> function, + triggered by function + <seealso marker="#try_load/3"><c>try_load/3</c></seealso>, where the monitor is created <em>because</em> the driver is in such a pending state.</p> - <p>Setting a driver monitor for <c>loading</c> will - eventually lead to one of the following messages + <p>Setting a driver monitor for <c>loading</c> + eventually leads to one of the following messages being sent:</p> <taglist> - <tag><em>{'UP', reference(), driver, Name, loaded}</em></tag> + <tag><c>{'UP', reference(), driver, Name, loaded}</c></tag> <item> - <p>This message is sent, either immediately if the + <p>This message is sent either immediately if the driver is already loaded and no reloading is pending, or when reloading is executed if reloading is pending. </p> <p>The <seealso marker="#users">user</seealso> is - expected to know if reloading is demanded prior - to creating a monitor for loading.</p> + expected to know if reloading is demanded before + creating a monitor for loading.</p> </item> - <tag><em>{'UP', reference(), driver, Name, permanent}</em></tag> + <tag><c>{'UP', reference(), driver, Name, permanent}</c></tag> <item> - <p>This message will be sent if reloading was + <p>This message is sent if reloading was expected, but the (old) driver made itself - permanent prior to reloading. It will also be + permanent before reloading. It is also sent if the driver was permanent or statically - linked in when trying to create the monitor.</p> + linked-in when trying to create the monitor.</p> </item> - <tag><em>{'DOWN', reference(), driver, Name, load_cancelled}</em></tag> + <tag><c>{'DOWN', reference(), driver, Name, load_cancelled}</c></tag> <item> - <p>This message will arrive if reloading was - underway, but the <seealso marker="#users">user</seealso> having requested - reload cancelled it by either dying or calling - <seealso marker="#try_unload/2">try_unload/2</seealso> + <p>This message arrives if reloading was + underway, but the requesting + <seealso marker="#users">user</seealso> + cancelled it by dying or calling + <seealso marker="#try_unload/2"><c>try_unload/2</c></seealso> (or <c>unload/1</c>/<c>unload_driver/1</c>) again before it was reloaded.</p> </item> - <tag><em>{'DOWN', reference(), driver, Name, {load_failure, Failure}}</em></tag> + <tag><c>{'DOWN', reference(), driver, Name, {load_failure, Failure}}</c></tag> <item> - <p>This message will arrive if reloading was + <p>This message arrives if reloading was underway but the loading for some reason failed. The <c>Failure</c> term is one of the - errors that can be returned from <seealso marker="#try_load/3">try_load/3</seealso>. The - error term can be passed to <seealso marker="#format_error/1">format_error/1</seealso> - for translation into human readable form. Note - that the translation has to be done in the same - running erlang virtual machine as the error + errors that can be returned from + <seealso marker="#try_load/3"><c>try_load/3</c></seealso>. + The error term can be passed to + <seealso marker="#format_error/1"><c>format_error/1</c></seealso> + for translation into human readable form. Notice + that the translation must be done in the same + running Erlang virtual machine as the error was detected in.</p> </item> </taglist> </item> - <tag><em>unloaded</em></tag> + <tag><c>unloaded</c></tag> <item> - <p>Monitor when a driver gets unloaded. If one + <p>Monitors when a driver gets unloaded. If one monitors a driver that is not present in the system, - one will immediately get notified that the driver got + one immediately gets notified that the driver got unloaded. There is no guarantee that the driver was - actually ever loaded.</p> - <p>A driver monitor for unload will eventually result + ever loaded.</p> + <p>A driver monitor for unload eventually results in one of the following messages being sent:</p> <taglist> - <tag><em>{'DOWN', reference(), driver, Name, unloaded}</em></tag> + <tag><c>{'DOWN', reference(), driver, Name, unloaded}</c></tag> <item> - <p>The driver instance monitored is now - unloaded. As the unload might have been due to a - <c>reload/2</c> request, the driver might once + <p>The monitored driver instance is now + unloaded. As the unload can be a result of a + <c>reload/2</c> request, the driver can once again have been loaded when this message arrives.</p> </item> - <tag><em>{'UP', reference(), driver, Name, unload_cancelled}</em></tag> + <tag><c>{'UP', reference(), driver, Name, unload_cancelled}</c></tag> <item> - <p>This message will be sent if unloading was + <p>This message is sent if unloading was expected, but while the driver was waiting for - all ports to get closed, a new <seealso marker="#users">user</seealso> of the driver - appeared and the unloading was cancelled.</p> - <p>This message appears when an <c>{ok, pending_driver}</c>) was returned from <seealso marker="#try_unload/2">try_unload/2</seealso>) - for the last <seealso marker="#users">user</seealso> of the driver and - then a <c>{ok, already_loaded}</c> is returned - from a call to <seealso marker="#try_load/3">try_load/3</seealso>.</p> - <p>If one wants to <em>really</em> monitor when the - driver gets unloaded, this message will distort - the picture, no unloading was really done. - The <c>unloaded_only</c> option creates a monitor - similar to an <c>unloaded</c> monitor, but does - never result in this message.</p> + all ports to get closed, a new + <seealso marker="#users">user</seealso> of the driver + appeared, and the unloading was cancelled.</p> + <p>This message appears if <c>{ok, pending_driver}</c> + was returned from + <seealso marker="#try_unload/2"><c>try_unload/2</c></seealso> + for the last <seealso marker="#users">user</seealso> + of the driver, and then <c>{ok, already_loaded}</c> is returned + from a call to + <seealso marker="#try_load/3"><c>try_load/3</c></seealso>.</p> + <p>If one <em>really</em> wants to monitor when the + driver gets unloaded, this message distorts + the picture, because no unloading was done. + Option <c>unloaded_only</c> creates a monitor + similar to an <c>unloaded</c> monitor, but + never results in this message.</p> </item> - <tag><em>{'UP', reference(), driver, Name, permanent}</em></tag> + <tag><c>{'UP', reference(), driver, Name, permanent}</c></tag> <item> - <p>This message will be sent if unloading was + <p>This message is sent if unloading was expected, but the driver made itself - permanent prior to unloading. It will also be + permanent before unloading. It is also sent if trying to monitor a permanent or - statically linked in driver.</p> + statically linked-in driver.</p> </item> </taglist> </item> - <tag><em>unloaded_only</em></tag> + <tag><c>unloaded_only</c></tag> <item> <p>A monitor created as <c>unloaded_only</c> behaves - exactly as one created as <c>unloaded</c> with the - exception that the <c>{'UP', reference(), driver, Name, unload_cancelled}</c> message will never be - sent, but the monitor instead persists until the - driver <em>really</em> gets unloaded.</p> + exactly as one created as <c>unloaded</c> + except that the + <c>{'UP', reference(), driver, Name, unload_cancelled}</c> + message is never sent, but the monitor instead persists until + the driver <em>really</em> gets unloaded.</p> </item> </taglist> </item> </taglist> <p>The function throws a <c>badarg</c> exception if the - parameters are not given as described above. </p> + parameters are not specified as described here.</p> </desc> </func> <func> <name name="reload" arity="2"/> - <fsummary>Replace a driver</fsummary> + <fsummary>Replace a driver.</fsummary> <desc> <p>Reloads the driver named <c><anno>Name</anno></c> from a possibly - different <c><anno>Path</anno></c> than was previously used. This - function is used in the code change <seealso marker="#scenarios">scenario</seealso> described in the + different <c><anno>Path</anno></c> than previously used. This + function is used in the code change + <seealso marker="#scenarios"><c>scenario</c></seealso> described in the introduction.</p> <p>If there are other <seealso marker="#users">users</seealso> - of this driver, the function will return <c>{error, pending_process}</c>, but if there are no more users, the - function call will hang until all open ports are closed.</p> + of this driver, the function returns <c>{error, pending_process}</c>, + but if there are no other users, the function call hangs until all + open ports are closed.</p> <note> - <p>Avoid mixing - several <seealso marker="#users">users</seealso> - with driver reload requests.</p> - </note> - <p>If one wants to avoid hanging on open ports, one should use - the <seealso marker="#try_load/3">try_load/3</seealso> - function instead.</p> - <p>The <c><anno>Name</anno></c> and <c><anno>Path</anno></c> parameters have exactly the - same meaning as when calling the plain <seealso marker="#load/2">load/2</seealso> function.</p> - <note> - <p>Avoid mixing - several <seealso marker="#users">users</seealso> - with driver reload requests.</p> + <p>Avoid mixing multiple + <seealso marker="#users">users</seealso> + with driver reload requests.</p> </note> + <p>To avoid hanging on open ports, use function + <seealso marker="#try_load/3"><c>try_load/3</c></seealso> + instead.</p> + <p>The <c><anno>Name</anno></c> and <c><anno>Path</anno></c> parameters + have exactly the same meaning as when calling the plain function + <seealso marker="#load/2"><c>load/2</c></seealso>.</p> + <p>On success, the function returns <c>ok</c>. On - failure, the function returns an opaque error, with the - exception of the <c>pending_process</c> error described - above. The opaque errors are to be translated into human - readable form by the <seealso marker="#format_error/1">format_error/1</seealso> function.</p> - <p>For more control over the error handling, again use the - <seealso marker="#try_load/3">try_load/3</seealso> + failure, the function returns an opaque error, + except the <c>pending_process</c> error described + earlier. The opaque errors are to be translated into human + readable form by function + <seealso marker="#format_error/1"><c>format_error/1</c></seealso>.</p> + <p>For more control over the error handling, use the + <seealso marker="#try_load/3"><c>try_load/3</c></seealso> interface instead.</p> <p>The function throws a <c>badarg</c> exception if the - parameters are not given as described above. </p> + parameters are not specified as described here.</p> </desc> </func> <func> <name name="reload_driver" arity="2"/> - <fsummary>Replace a driver</fsummary> + <fsummary>Replace a driver.</fsummary> <desc> - <p>Works exactly as <seealso marker="#reload/2">reload/2</seealso>, but for drivers - loaded with the <seealso marker="#load_driver/2">load_driver/2</seealso> interface. </p> - <p>As this interface implies that ports are being killed when - the last user disappears, the function wont hang waiting for + <p>Works exactly as <seealso marker="#reload/2"><c>reload/2</c></seealso>, + but for drivers loaded with the + <seealso marker="#load_driver/2"><c>load_driver/2</c></seealso> interface.</p> + <p>As this interface implies that ports are killed when + the last user disappears, the function does not hang waiting for ports to get closed.</p> - <p>For further details, see the <seealso marker="#scenarios">scenarios</seealso> in the module - description and refer to the <seealso marker="#reload/2">reload/2</seealso> function description.</p> + <p>For more details, see + <seealso marker="#scenarios"><c>scenarios</c></seealso> in this module + description and the function description for + <seealso marker="#reload/2"><c>reload/2</c></seealso>.</p> <p>The function throws a <c>badarg</c> exception if the - parameters are not given as described above. </p> + parameters are not specified as described here.</p> </desc> </func> <func> <name name="try_load" arity="3"/> - <fsummary>Load a driver</fsummary> + <fsummary>Load a driver.</fsummary> <desc> - <p>This function provides more control than the + <p>Provides more control than the <c>load/2</c>/<c>reload/2</c> and <c>load_driver/2</c>/<c>reload_driver/2</c> interfaces. It - will never wait for completion of other operations related - to the driver, but immediately return the status of the - driver as either:</p> + never waits for completion of other operations related + to the driver, but immediately returns the status of the + driver as one of the following:</p> <taglist> - <tag><em>{ok, loaded}</em></tag> + <tag><c>{ok, loaded}</c></tag> <item> - <p>The driver was actually loaded and is immediately - usable.</p> + <p>The driver was loaded and is immediately usable.</p> </item> - <tag><em>{ok, already_loaded}</em></tag> + <tag><c>{ok, already_loaded}</c></tag> <item> <p>The driver was already loaded by another process - and/or is in use by a living port. The load by you is + or is in use by a living port, or both. The load by you is registered and a corresponding <c>try_unload</c> is expected sometime in the future.</p> </item> - <tag><em>{ok, pending_driver}</em>or <em>{ok, pending_driver, reference()}</em></tag> + <tag><c>{ok, pending_driver}</c>or <c>{ok, pending_driver, reference()}</c></tag> <item> <p>The load request is registered, but the loading is - delayed due to the fact that an earlier instance of the - driver is still waiting to get unloaded (there are open - ports using it). Still, unload is expected when you are - done with the driver. This return value will - <em>mostly</em> happen when the + delayed because an earlier instance of the + driver is still waiting to get unloaded (open + ports use it). Still, unload is expected when you are + done with the driver. This return value + <em>mostly</em> occurs when options <c>{reload,pending_driver}</c> or - <c>{reload,pending}</c> options are used, but - <em>can</em> happen when another <seealso marker="#users">user</seealso> is unloading a driver in - parallel and the <c>kill_ports</c> driver option is - set. In other words, this return value will always need - to be handled!</p> + <c>{reload,pending}</c> are used, but + <em>can</em> occur when another + <seealso marker="#users">user</seealso> is unloading a + driver in parallel and driver option <c>kill_ports</c> is set. + In other words, this return value always needs + to be handled.</p> </item> - <tag><em>{ok, pending_process}</em>or <em>{ok, pending_process, reference()}</em></tag> + <tag><c>{ok, pending_process}</c>or <c>{ok, pending_process, reference()}</c></tag> <item> <p>The load request is registered, but the loading is - delayed due to the fact that an earlier instance of the + delayed because an earlier instance of the driver is still waiting to get unloaded by another <seealso marker="#users">user</seealso> (not only by a port, in which case <c>{ok,pending_driver}</c> would have been returned). Still, unload is expected when you - are done with the driver. This return value will - <em>only</em> happen when the <c>{reload,pending}</c> - option is used.</p> + are done with the driver. This return value + <em>only</em> occurs when option <c>{reload,pending}</c> + is used.</p> </item> </taglist> <p>When the function returns <c>{ok, pending_driver}</c> or - <c>{ok, pending_process}</c>, one might want to get information - about when the driver is <em>actually</em> loaded. This can - be achieved by using the <c>{monitor, <anno>MonitorOption</anno>}</c> option.</p> - <p>When monitoring is requested, and a corresponding <c>{ok, pending_driver}</c> or <c>{ok, pending_process}</c> would be - returned, the function will instead return a tuple <c>{ok, <anno>PendingStatus</anno>, reference()}</c> and the process will, at a later - time when the driver actually gets loaded, get a monitor - message. The monitor message one can expect is described in - the <seealso marker="#monitor/2">monitor/2</seealso> - function description. </p> + <c>{ok, pending_process}</c>, one can get information + about when the driver is <em>actually</em> loaded by using + option <c>{monitor, <anno>MonitorOption</anno>}</c>.</p> + <p>When monitoring is requested, and a corresponding + <c>{ok, pending_driver}</c> or <c>{ok, pending_process}</c> would + be returned, the function instead returns a tuple + <c>{ok, <anno>PendingStatus</anno>, reference()}</c> + and the process then gets a monitor message later, when the + driver gets loaded. The monitor message to expect is described in + the function description of + <seealso marker="#monitor/2"><c>monitor/2</c></seealso>.</p> <note> - <p>Note that in case of loading, monitoring can - <em>not</em> only get triggered by using the <c>{reload, <anno>ReloadOption</anno>}</c> option, but also in special cases where - the load-error is transient, why <c>{monitor, pending_driver}</c> should be used under basically - <em>all</em> real world circumstances!</p> + <p>In case of loading, monitoring can <em>not</em> only get + triggered by using option <c>{reload, <anno>ReloadOption</anno>}</c>, + but also in special cases where the load error is transient. Thus, + <c>{monitor, pending_driver}</c> is to be used under basically + <em>all</em> real world circumstances.</p> </note> <p>The function accepts the following parameters:</p> <taglist> - <tag><em><c><anno>Path</anno></c></em></tag> + <tag><c><anno>Path</anno></c></tag> <item> - <p>The filesystem path to the directory where the driver - object file is situated. The filename of the object file + <p>The file system path to the directory where the driver + object file is located. The filename of the object file (minus extension) must correspond to the driver name - (used in the name parameter) and the driver must - identify itself with the very same name. The - <c><anno>Path</anno></c> might be provided as an <em>iolist()</em>, + (used in parameter <c><anno>Name</anno></c>) and the driver must + identify itself with the same name. + <c><anno>Path</anno></c> can be provided as an <em>iolist()</em>, meaning it can be a list of other <c>iolist()</c>s, characters - (eight bit integers) or binaries, all to be flattened + (8-bit integers), or binaries, all to be flattened into a sequence of characters.</p> <p>The (possibly flattened) <c><anno>Path</anno></c> parameter must be - consistent throughout the system, a driver should, by + consistent throughout the system. A driver is to, by all <seealso marker="#users">users</seealso>, be loaded - using the same <em>literal</em><c><anno>Path</anno></c>. The - exception is when <em>reloading</em> is requested, in - which case the <c><anno>Path</anno></c> may be specified - differently. Note that all <seealso marker="#users">users</seealso> trying to load the - driver at a later time will need to use the <em>new</em><c><anno>Path</anno></c> if the <c><anno>Path</anno></c> is changed using a - <c>reload</c> option. This is yet another reason + using the same <em>literal</em> <c><anno>Path</anno></c>. + The exception is when <em>reloading</em> is requested, + in which case <c><anno>Path</anno></c> can be specified + differently. Notice that all + <seealso marker="#users">users</seealso> trying to load the + driver later need to use the + <em>new</em> <c><anno>Path</anno></c> if <c><anno>Path</anno></c> + is changed using a <c>reload</c> option. This is yet another reason to have <em>only one loader</em> of a driver one wants to - upgrade in a running system! </p> + upgrade in a running system.</p> </item> - <tag><em><c><anno>Name</anno></c></em></tag> + <tag><c><anno>Name</anno></c></tag> <item> - <p>The name parameter is the name of the driver to be used - in subsequent calls to <seealso marker="erts:erlang#open_port/2">open_port</seealso>. The - name can be specified either as an <c>iolist()</c> or - as an <c>atom()</c>. The name given when loading is used - to find the actual object file (with the - help of the <c><anno>Path</anno></c> and the system implied - extension suffix, i.e. <c>.so</c>). The name by which - the driver identifies itself must also be consistent - with this <c><anno>Name</anno></c> parameter, much as a beam-file's - module name much correspond to its filename.</p> + <p>This parameter is the name of the driver + to be used in subsequent calls to function + <seealso marker="erts:erlang#open_port/2"><c>erlang:open_port</c></seealso> + in <c>ERTS</c>. + The name can be specified as an <c>iolist()</c> or + an <c>atom()</c>. The name specified when loading is used + to find the object file (with the help of <c><anno>Path</anno></c> + and the system-implied extension suffix, that is, <c>.so</c>). + The name by which the driver identifies itself must also be consistent + with this <c><anno>Name</anno></c> parameter, much as + the module name of a Beam file much corresponds to its filename.</p> </item> - <tag><em><c><anno>OptionList</anno></c></em></tag> + <tag><c><anno>OptionList</anno></c></tag> <item> - <p>A number of options can be specified to control the - loading operation. The options are given as a list of - two-tuples, the tuples having the following values and + <p>Some options can be specified to control the + loading operation. The options are specified as a list of + two-tuples. The tuples have the following values and meanings:</p> <taglist> - <tag><em>{driver_options, <c><anno>DriverOptionList</anno></c>}</em></tag> + <tag><c>{driver_options, <anno>DriverOptionList</anno>}</c></tag> <item> - <p>This option is to provide options that will change - its general behavior and will "stick" to the driver + <p>This is to provide options that changes + its general behavior and "sticks" to the driver throughout its lifespan.</p> - <p>The driver options for a given driver name need - always to be consistent, <em>even when the driver is reloaded</em>, meaning that they are as much a part - of the driver as the actual name.</p> - <p>Currently the only allowed driver option is + <p>The driver options for a specified driver name need + always to be consistent, <em>even when the driver is reloaded</em>, + meaning that they are as much a part of the driver as the name.</p> + <p>The only allowed driver option is <c>kill_ports</c>, which means that all ports opened - towards the driver are killed with the exit-reason + to the driver are killed with exit reason <c>driver_unloaded</c> when no process any longer has the driver loaded. This situation arises either - when the last <seealso marker="#users">user</seealso> calls <seealso marker="#try_unload/2">try_unload/2</seealso>, or - the last process having loaded the driver exits.</p> + when the last <seealso marker="#users">user</seealso> calls + <seealso marker="#try_unload/2"><c>try_unload/2</c></seealso>, or + when the last process having loaded the driver exits.</p> </item> - <tag><em>{monitor, <c><anno>MonitorOption</anno></c>}</em></tag> + <tag><c>{monitor, <anno>MonitorOption</anno>}</c></tag> <item> <p>A <c><anno>MonitorOption</anno></c> tells <c>try_load/3</c> to trigger a driver monitor under certain conditions. When the monitor is triggered, the - function will return a three-tuple <c>{ok, <anno>PendingStatus</anno>, reference()}</c>, where the <c>reference()</c> is - the monitor ref for the driver monitor.</p> - <p>Only one <c><anno>MonitorOption</anno></c> can be specified and - it is either the atom <c>pending</c>, which means - that a monitor should be created whenever a load - operation is delayed, and the atom - <c>pending_driver</c>, in which a monitor is - created whenever the operation is delayed due to - open ports towards an otherwise unused driver. The - <c>pending_driver</c> option is of little use, but - is present for completeness, it is very well defined - which reload-options might give rise to which - delays. It might, however, be a good idea to use the - same <c><anno>MonitorOption</anno></c> as the <c><anno>ReloadOption</anno></c> - if present.</p> - <p>If reloading is not requested, it might still be - useful to specify the <c>monitor</c> option, as - forced unloads (<c>kill_ports</c> driver option or - the <c>kill_ports</c> option to <seealso marker="#try_unload/2">try_unload/2</seealso>) will - trigger a transient state where driver loading + function returns a three-tuple + <c>{ok, <anno>PendingStatus</anno>, reference()}</c>, where + <c>reference()</c> is the monitor reference for the driver monitor.</p> + <p>Only one <c><anno>MonitorOption</anno></c> can be specified. + It is one of the following:</p> + <list type="bulleted"> + <item> + <p>The atom <c>pending</c>, which means + that a monitor is to be created whenever a load + operation is delayed,</p> + </item> + <item> + <p>The atom <c>pending_driver</c>, in which a monitor + is created whenever the operation is delayed because + of open ports to an otherwise unused driver.</p> + </item> + </list> + <p>Option <c>pending_driver</c> is of little use, but + is present for completeness, as it is well defined which + reload options that can give rise to which delays. + However, it can be a good idea to use the same + <c><anno>MonitorOption</anno></c> as the + <c><anno>ReloadOption</anno></c>, if present.</p> + <p>If reloading is not requested, it can still be + useful to specify option <c>monitor</c>, as + forced unloads (driver option <c>kill_ports</c> or + option <c>kill_ports</c> to + <seealso marker="#try_unload/2"><c>try_unload/2</c></seealso>) + trigger a transient state where driver loading cannot be performed until all closing ports are - actually closed. So, as <c>try_unload</c> can, in - almost all situations, return <c>{ok, pending_driver}</c>, one should always specify at least - <c>{monitor, pending_driver}</c> in production - code (see the monitor discussion above). </p> + closed. Thus, as <c>try_unload</c> can, in + almost all situations, return <c>{ok, pending_driver}</c>, + always specify at least <c>{monitor, pending_driver}</c> + in production code (see the monitor discussion earlier).</p> </item> - <tag><em>{reload, <c><anno>ReloadOption</anno></c>}</em></tag> + <tag><c>{reload, <anno>ReloadOption</anno>}</c></tag> <item> - <p>This option is used when one wants to + <p>This option is used to <em>reload</em> a driver from disk, most often in a code upgrade scenario. Having a <c>reload</c> option - also implies that the <c><anno>Path</anno></c> parameter need - <em>not</em> be consistent with earlier loads of + also implies that parameter <c><anno>Path</anno></c> does + <em>not</em> need to be consistent with earlier loads of the driver.</p> - <p>To reload a driver, the process needs to have previously - loaded the driver, i.e there has to be an active <seealso marker="#users">user</seealso> of the driver in the process. </p> - <p>The <c>reload</c> option can be either the atom - <c>pending</c>, in which reloading is requested for - any driver and will be effectuated when <em>all</em> - ports opened against the driver are closed. The - replacement of the driver will in this case take - place regardless of if there are still - pending <seealso marker="#users">users</seealso> - having the driver loaded! - The option also triggers port-killing (if the - <c>kill_ports</c> driver option is used) even though - there are pending users, making it usable for forced - driver replacement, but laying a lot of - responsibility on the driver <seealso marker="#users">users</seealso>. The pending option is - seldom used as one does not want other <seealso marker="#users">users</seealso> to have loaded the - driver when code change is underway. </p> - <p>The more useful option is <c>pending_driver</c>, - which means that reloading will be queued if the - driver is <em>not</em> loaded by any other <seealso marker="#users">users</seealso>, but the driver has - opened ports, in which case <c>{ok, pending_driver}</c> will be returned (a - <c>monitor</c> option is of course recommended).</p> - <p>If the driver is unloaded (not present in the - system), the error code - <c>not_loaded</c> will be returned. The - <c>reload</c> option is intended for when the user + <p>To reload a driver, the process must have loaded the driver + before, that is, there must be an active + <seealso marker="#users">user</seealso> of the driver + in the process.</p> + <p>The <c>reload</c> option can be either of the following:</p> + <taglist> + <tag><c>pending</c></tag> + <item> + <p>With the atom <c>pending</c>, reloading is requested + for any driver and is effectuated when <em>all</em> + ports opened to the driver are closed. The driver + replacement in this case takes + place regardless if there are still + pending <seealso marker="#users">users</seealso> + having the driver loaded.</p> + <p>The option also triggers port-killing (if driver + option <c>kill_ports</c> is used) although + there are pending users, making it usable for forced + driver replacement, but laying much + responsibility on the driver + <seealso marker="#users">users</seealso>. + The pending option is seldom used as one does not want other + <seealso marker="#users">users</seealso> to have loaded + the driver when code change is underway.</p></item> + <tag><c>pending_driver</c></tag> + <item> + <p>This option is more useful. Here, reloading is queued + if the driver is <em>not</em> loaded by any other + <seealso marker="#users">users</seealso>, but the + driver has opened ports, in which case + <c>{ok, pending_driver}</c> is returned + (a <c>monitor</c> option is recommended).</p></item> + </taglist> + <p>If the driver is unloaded (not present in the system), + error code <c>not_loaded</c> is returned. Option + <c>reload</c> is intended for when the user has already loaded the driver in advance.</p> </item> </taglist> </item> </taglist> - <p>The function might return numerous errors, of which some - only can be returned given a certain combination of options.</p> - <p>A number of errors are opaque and can only be interpreted by - passing them to the <seealso marker="#format_error/1">format_error/1</seealso> function, + <p>The function can return numerous errors, some + can only be returned given a certain combination of options.</p> + <p>Some errors are opaque and can only be interpreted by + passing them to function + <seealso marker="#format_error/1"><c>format_error/1</c></seealso>, but some can be interpreted directly:</p> <taglist> - <tag><em>{error,linked_in_driver}</em></tag> + <tag><c>{error,linked_in_driver}</c></tag> <item> - <p>The driver with the specified name is an erlang - statically linked in driver, which cannot be manipulated + <p>The driver with the specified name is an Erlang + statically linked-in driver, which cannot be manipulated with this API.</p> </item> - <tag><em>{error,inconsistent}</em></tag> + <tag><c>{error,inconsistent}</c></tag> <item> - <p>The driver has already been loaded with either other - <c><anno>DriverOptionList</anno></c> or a different <em>literal</em><c>Path</c> argument.</p> - <p>This can happen even if a <c>reload</c> option is given, - if the <c>DriverOptionList</c> differ from the current.</p> + <p>The driver is already loaded with other + <c><anno>DriverOptionList</anno></c> or a different + <em>literal</em> <c>Path</c> argument.</p> + <p>This can occur even if a <c>reload</c> option is specified, + if <c>DriverOptionList</c> differs from the current.</p> </item> - <tag><em>{error, permanent}</em></tag> + <tag><c>{error, permanent}</c></tag> <item> <p>The driver has requested itself to be permanent, making - it behave like an erlang linked in driver and it can no + it behave like an Erlang linked-in driver and can no longer be manipulated with this API.</p> </item> - <tag><em>{error, pending_process}</em></tag> + <tag><c>{error, pending_process}</c></tag> <item> - <p>The driver is loaded by other <seealso marker="#users">users</seealso> when the <c>{reload, pending_driver}</c> option was given.</p> + <p>The driver is loaded by other + <seealso marker="#users">users</seealso> when + option <c>{reload, pending_driver}</c> was specified.</p> </item> - <tag><em>{error, pending_reload}</em></tag> + <tag><c>{error, pending_reload}</c></tag> <item> - <p>Driver reload is already requested by another <seealso marker="#users">user</seealso> when the <c>{reload, <anno>ReloadOption</anno>}</c> option was given.</p> + <p>Driver reload is already requested by another + <seealso marker="#users">user</seealso> when option + <c>{reload, <anno>ReloadOption</anno>}</c> was specified.</p> </item> - <tag><em>{error, not_loaded_by_this_process}</em></tag> + <tag><c>{error, not_loaded_by_this_process}</c></tag> <item> - <p>Appears when the <c>reload</c> option is given. The - driver <c><anno>Name</anno></c> is present in the system, but there is no - <seealso marker="#users">user</seealso> of it in this + <p>Appears when option <c>reload</c> is specified. The + driver <c><anno>Name</anno></c> is present in the system, but there + is no <seealso marker="#users">user</seealso> of it in this process.</p> </item> - <tag><em>{error, not_loaded}</em></tag> + <tag><c>{error, not_loaded}</c></tag> <item> - <p>Appears when the <c>reload</c> option is given. The + <p>Appears when option <c>reload</c> is specified. The driver <c><anno>Name</anno></c> is not in the system. Only drivers loaded by this process can be reloaded.</p> </item> </taglist> - <p>All other error codes are to be translated by the <seealso marker="#format_error/1">format_error/1</seealso> - function. Note that calls to <c>format_error</c> should be - performed from the same running instance of the erlang - virtual machine as the error was detected in, due to system - dependent behavior concerning error values.</p> - <p>If the arguments or options are malformed, the function will - throw a <c>badarg</c> exception.</p> + <p>All other error codes are to be translated by function + <seealso marker="#format_error/1"><c>format_error/1</c></seealso>. + Notice that calls to <c>format_error</c> are to be + performed from the same running instance of the Erlang + virtual machine as the error is detected in, because of + system-dependent behavior concerning error values.</p> + <p>If the arguments or options are malformed, the function + throws a <c>badarg</c> exception.</p> </desc> </func> <func> <name name="try_unload" arity="2"/> - <fsummary>Unload a driver</fsummary> + <fsummary>Unload a driver.</fsummary> <desc> - <p>This is the low level function to unload (or decrement + <p>This is the low-level function to unload (or decrement reference counts of) a driver. It can be used to force port killing, in much the same way as the driver option - <c>kill_ports</c> implicitly does, and it can trigger a - monitor either due to other <seealso marker="#users">users</seealso> still having the driver - loaded or that there are open ports using the driver.</p> + <c>kill_ports</c> implicitly does. Also, it can trigger a + monitor either because other + <seealso marker="#users">users</seealso> still have the driver + loaded or because open ports use the driver.</p> <p>Unloading can be described as the process of telling the emulator that this particular part of the code in this - particular process (i.e. this <seealso marker="#users">user</seealso>) no longer needs the - driver. That can, if there are no other users, trigger - actual unloading of the driver, in which case the driver - name disappears from the system and (if possible) the memory - occupied by the driver executable code is reclaimed. If the - driver has the <c>kill_ports</c> option set, or if - <c>kill_ports</c> was specified as an option to this - function, all pending ports using this driver will get - killed when unloading is done by the last <seealso marker="#users">user</seealso>. If no port-killing is - involved and there are open ports, the actual unloading - is delayed until there are no more open ports using the - driver. If, in this case, another <seealso marker="#users">user</seealso> (or even this user) loads the - driver again before the driver is actually unloaded, the - unloading will never take place.</p> - <p>To allow the <seealso marker="#users">user</seealso> that - <em>requests unloading</em> to wait for <em>actual unloading</em> to - take place, <c>monitor</c> triggers can be specified in much - the same way as when loading. As <seealso marker="#users">users</seealso> of this function however - seldom are interested in more than decrementing the - reference counts, monitoring is more seldom needed. If the - <c>kill_ports</c> option is used however, monitor trigging is - crucial, as the ports are not guaranteed to have been killed - until the driver is unloaded, why a monitor should be - triggered for at least the <c>pending_driver</c> case.</p> - <p>The possible monitor messages that can be expected are the - same as when using the <c>unloaded</c> option to the - <seealso marker="#monitor/2">monitor/2</seealso> function.</p> - <p>The function will return one of the following statuses upon + particular process (that is, this + <seealso marker="#users">user</seealso>) no longer needs + the driver. That can, if there are no other users, trigger + unloading of the driver, in which case the driver name + disappears from the system and (if possible) the memory + occupied by the driver executable code is reclaimed.</p> + <p>If the driver has option <c>kill_ports</c> set, or if + <c>kill_ports</c> is specified as an option to this + function, all pending ports using this driver are + killed when unloading is done by the last + <seealso marker="#users">user</seealso>. If no port-killing + is involved and there are open ports, the unloading + is delayed until no more open ports use the + driver. If, in this case, another + <seealso marker="#users">user</seealso> (or even this user) + loads the driver again before the driver is unloaded, the + unloading never takes place.</p> + <p>To allow the <seealso marker="#users">user</seealso> to + <em>request unloading</em> to wait for <em>actual unloading</em>, + <c>monitor</c> triggers can be specified in much the same way as + when loading. However, as <seealso marker="#users">users</seealso> + of this function seldom are interested in more than decrementing the + reference counts, monitoring is seldom needed.</p> + <note><p> If option <c>kill_ports</c> is used, monitor trigging is crucial, + as the ports are not guaranteed to be killed until the driver is unloaded. + Thus, a monitor must be triggered for at least the <c>pending_driver</c> + case.</p></note> + <p>The possible monitor messages to expect are the + same as when using option <c>unloaded</c> to function + <seealso marker="#monitor/2"><c>monitor/2</c></seealso>.</p> + <p>The function returns one of the following statuses upon success:</p> <taglist> - <tag><em>{ok, unloaded}</em></tag> + <tag><c>{ok, unloaded}</c></tag> <item> <p>The driver was immediately unloaded, meaning that the driver name is now free to use by other drivers and, if the underlying OS permits it, the memory occupied by the driver object code is now reclaimed.</p> <p>The driver can only be unloaded when there are no open - ports using it and there are no more <seealso marker="#users">users</seealso> requiring it to be + ports using it and no more + <seealso marker="#users">users</seealso> require it to be loaded.</p> </item> - <tag><em>{ok, pending_driver}</em>or <em>{ok, pending_driver, reference()}</em></tag> + <tag><c>{ok, pending_driver}</c>or + <c>{ok, pending_driver, reference()}</c></tag> <item> - <p>This return value indicates that this call removed the - last <seealso marker="#users">user</seealso> from the + <p>Indicates that this call removed the last + <seealso marker="#users">user</seealso> from the driver, but there are still open ports using it. - When all ports are closed and no new <seealso marker="#users">users</seealso> have arrived, the driver - will actually be reloaded and the name and memory + When all ports are closed and no new + <seealso marker="#users">users</seealso> have arrived, + the driver is reloaded and the name and memory reclaimed.</p> - <p>This return value is valid even when the option - <c>kill_ports</c> was used, as killing ports may not be - a process that completes immediately. The condition is, - in that case, however transient. Monitors are as always - useful to detect when the driver is really unloaded.</p> + <p>This return value is valid even if option <c>kill_ports</c> + was used, as killing ports can be a process that does not + complete immediately. However, the condition is in that case + transient. Monitors are always useful to detect when the driver + is really unloaded.</p> </item> - <tag><em>{ok, pending_process}</em>or <em>{ok, pending_process, reference()}</em></tag> + <tag><c>{ok, pending_process}</c>or + <c>{ok, pending_process, reference()}</c></tag> <item> - <p>The unload request is registered, but there are still - other <seealso marker="#users">users</seealso> holding - the driver. Note that the term <c>pending_process</c> - might refer to the running process, there might be more + <p>The unload request is registered, but + other <seealso marker="#users">users</seealso> still hold + the driver. Notice that the term <c>pending_process</c> + can refer to the running process; there can be more than one <seealso marker="#users">user</seealso> in the same process.</p> - <p>This is a normal, healthy return value if the call was + <p>This is a normal, healthy, return value if the call was just placed to inform the emulator that you have no - further use of the driver. It is actually the most - common return value in the most common <seealso marker="#scenarios">scenario</seealso> + further use of the driver. It is the most + common return value in the most common + <seealso marker="#scenarios"><c>scenario</c></seealso> described in the introduction.</p> </item> </taglist> <p>The function accepts the following parameters:</p> <taglist> - <tag><em><c><anno>Name</anno></c></em></tag> + <tag><c><anno>Name</anno></c></tag> <item> - <p>The name parameter is the name of the driver to be - unloaded. The name can be specified either as an - <c>iolist()</c> or as an <c>atom()</c>. </p> + <p><c><anno>Name</anno></c> is the name of the + driver to be unloaded. The name can be specified as an + <c>iolist()</c> or as an <c>atom()</c>.</p> </item> - <tag><em><c><anno>OptionList</anno></c></em></tag> + <tag><c><anno>OptionList</anno></c></tag> <item> - <p>The <c><anno>OptionList</anno></c> argument can be used to specify - certain behavior regarding ports as well as triggering + <p>Argument <c><anno>OptionList</anno></c> can be used to specify + certain behavior regarding ports and triggering monitors under certain conditions:</p> <taglist> - <tag><em>kill_ports</em></tag> + <tag><c>kill_ports</c></tag> <item> - <p>Force killing of all ports opened using this driver, - with the exit reason <c>driver_unloaded</c>, if you are - the <em>last</em><seealso marker="#users">user</seealso> of the driver.</p> - <p>If there are other <seealso marker="#users">users</seealso> having the driver - loaded, this option will have no effect.</p> - <p>If one wants the consistent behavior of killing ports + <p>Forces killing of all ports opened using this driver, + with exit reason <c>driver_unloaded</c>, if you are + the <em>last</em> <seealso marker="#users">user</seealso> + of the driver.</p> + <p>If other <seealso marker="#users">users</seealso> + have the driver loaded, this option has no effect.</p> + <p>To get the consistent behavior of killing ports when the last <seealso marker="#users">user</seealso> - unloads, one should use the driver option + unloads, use driver option <c>kill_ports</c> when loading the driver instead.</p> </item> - <tag><em>{monitor, <c><anno>MonitorOption</anno></c>}</em></tag> + <tag><c>{monitor, <anno>MonitorOption</anno>}</c></tag> <item> - <p>This option creates a driver monitor if the condition - given in <c><anno>MonitorOption</anno></c> is true. The valid + <p>Creates a driver monitor if the condition + specified in <c><anno>MonitorOption</anno></c> is true. The valid options are:</p> <taglist> - <tag><em>pending_driver</em></tag> + <tag><c>pending_driver</c></tag> <item> - <p>Create a driver monitor if the return value is to + <p>Creates a driver monitor if the return value is to be <c>{ok, pending_driver}</c>.</p> </item> - <tag><em>pending</em></tag> + <tag><c>pending</c></tag> <item> - <p>Create a monitor if the return value will be either + <p>Creates a monitor if the return value is <c>{ok, pending_driver}</c> or <c>{ok, pending_process}</c>.</p> </item> </taglist> - <p>The <c>pending_driver</c> <c><anno>MonitorOption</anno></c> is by far - the most useful and it has to be used to ensure that the - driver has really been unloaded and the ports closed - whenever the <c>kill_ports</c> option is used or the - driver may have been loaded with the <c>kill_ports</c> - driver option.</p> - <p>By using the monitor-triggers in the call to - <c>try_unload</c> one can be sure that the monitor is - actually added before the unloading is executed, meaning - that the monitor will always get properly triggered, - which would not be the case if one called - <c>erl_ddll:monitor/2</c> separately.</p> + <p>The <c>pending_driver</c> <c><anno>MonitorOption</anno></c> is + by far the most useful. It must be used to ensure that the + driver really is unloaded and the ports closed + whenever option <c>kill_ports</c> is used, or the + driver can have been loaded with driver option + <c>kill_ports</c>.</p> + <p>Using the monitor triggers in the call to + <c>try_unload</c> ensures that the monitor is + added before the unloading is executed, meaning + that the monitor is always properly triggered, + which is not the case if <c>monitor/2</c> is called + separately.</p> </item> </taglist> </item> </taglist> - <p>The function may return several error conditions, of which - all are well specified (no opaque values):</p> + <p>The function can return the following error conditions, + all well specified (no opaque values):</p> <taglist> - <tag><em>{error, linked_in_driver}</em></tag> + <tag><c>{error, linked_in_driver}</c></tag> <item> - <p>You were trying to unload an erlang statically linked in + <p>You were trying to unload an Erlang statically linked-in driver, which cannot be manipulated with this interface (and cannot be unloaded at all).</p> </item> - <tag><em>{error, not_loaded}</em></tag> + <tag><c>{error, not_loaded}</c></tag> <item> <p>The driver <c><anno>Name</anno></c> is not present in the system.</p> </item> - <tag><em>{error, not_loaded_by_this_process}</em></tag> + <tag><c>{error, not_loaded_by_this_process}</c></tag> <item> <p>The driver <c><anno>Name</anno></c> is present in the system, but there is no <seealso marker="#users">user</seealso> of it in this process. </p> <p>As a special case, drivers can be unloaded from - processes that has done no corresponding call to - <c>try_load/3</c> if, and only if, there are <em>no users of the driver at all</em>, which may happen if the + processes that have done no corresponding call to + <c>try_load/3</c> if, and only if, there are + <em>no users of the driver at all</em>, which can occur if the process containing the last user dies.</p> </item> - <tag><em>{error, permanent}</em></tag> + <tag><c>{error, permanent}</c></tag> <item> <p>The driver has made itself permanent, in which case it can no longer be manipulated by this interface (much - like a statically linked in driver).</p> + like a statically linked-in driver).</p> </item> </taglist> <p>The function throws a <c>badarg</c> exception if the - parameters are not given as described above. </p> + parameters are not specified as described here.</p> </desc> </func> <func> <name name="unload" arity="1"/> - <fsummary>Unload a driver</fsummary> + <fsummary>Unload a driver.</fsummary> <desc> <p>Unloads, or at least dereferences the driver named - <c><anno>Name</anno></c>. If the caller is the last <seealso marker="#users">user</seealso> of the driver, and there - are no more open ports using the driver, the driver will - actually get unloaded. In all other cases, actual unloading - will be delayed until all ports are closed and there are no - remaining <seealso marker="#users">users</seealso>.</p> - <p>If there are other <seealso marker="#users">users</seealso> of the driver, the reference - counts of the driver is merely decreased, so that the caller - is no longer considered a user of the driver. For usage - scenarios, see the <seealso marker="#scenarios">description</seealso> in the beginning - of this document. </p> + <c><anno>Name</anno></c>. If the caller is the last + <seealso marker="#users">user</seealso> of the driver, + and no more open ports use the driver, the driver + gets unloaded. Otherwise, unloading + is delayed until all ports are closed and no + <seealso marker="#users">users</seealso> remain.</p> + <p>If there are other <seealso marker="#users">users</seealso> + of the driver, the reference counts of the driver is merely decreased, + so that the caller is no longer considered a + <seealso marker="#users">user</seealso> of the driver. For use + scenarios, see the <seealso marker="#scenarios"><c>description</c></seealso> + in the beginning of this module.</p> <p>The <c><anno>ErrorDesc</anno></c> returned is an opaque value to be - passed further on to the <seealso marker="#format_error/1">format_error/1</seealso> - function. For more control over the operation, use the - <seealso marker="#try_unload/2">try_unload/2</seealso> + passed further on to function + <seealso marker="#format_error/1"><c>format_error/1</c></seealso>. + For more control over the operation, use the + <seealso marker="#try_unload/2"><c>try_unload/2</c></seealso> interface.</p> <p>The function throws a <c>badarg</c> exception if the - parameters are not given as described above. </p> + parameters are not specified as described here.</p> </desc> </func> <func> <name name="unload_driver" arity="1"/> - <fsummary>Unload a driver</fsummary> + <fsummary>Unload a driver.</fsummary> <desc> <p>Unloads, or at least dereferences the driver named - <c><anno>Name</anno></c>. If the caller is the last <seealso marker="#users">user</seealso> of the driver, all - remaining open ports using the driver will get killed with - the reason <c>driver_unloaded</c> and the driver will - eventually get unloaded.</p> + <c><anno>Name</anno></c>. If the caller is the last + <seealso marker="#users">user</seealso> of the driver, all + remaining open ports using the driver are killed with + reason <c>driver_unloaded</c> and the driver + eventually gets unloaded.</p> <p>If there are other <seealso marker="#users">users</seealso> of the driver, the reference counts of the driver is merely decreased, so that the caller is no longer considered a <seealso marker="#users">user</seealso>. For - usage scenarios, see the <seealso marker="#scenarios">description</seealso> in the beginning - of this document.</p> + use scenarios, see the + <seealso marker="#scenarios"><c>description</c></seealso> in the + beginning of this module.</p> <p>The <c><anno>ErrorDesc</anno></c> returned is an opaque value to be - passed further on to the <seealso marker="#format_error/1">format_error/1</seealso> - function. For more control over the operation, use the - <seealso marker="#try_unload/2">try_unload/2</seealso> + passed further on to function + <seealso marker="#format_error/1"><c>format_error/1</c></seealso>. + For more control over the operation, use the + <seealso marker="#try_unload/2"><c>try_unload/2</c></seealso> interface.</p> <p>The function throws a <c>badarg</c> exception if the - parameters are not given as described above. </p> - </desc> - </func> - <func> - <name name="loaded_drivers" arity="0"/> - <fsummary>List loaded drivers</fsummary> - <desc> - <p>Returns a list of all the available drivers, both - (statically) linked-in and dynamically loaded ones.</p> - <p>The driver names are returned as a list of strings rather - than a list of atoms for historical reasons.</p> - <p>More information about drivers can be obtained using one of - the <seealso marker="#info/0">info</seealso> functions.</p> - </desc> - </func> - <func> - <name name="format_error" arity="1"/> - <fsummary>Format an error descriptor</fsummary> - <desc> - <p>Takes an <c><anno>ErrorDesc</anno></c> returned by load, unload or - reload functions and returns a string which - describes the error or warning.</p> - <note> - <p>Due to peculiarities in the dynamic loading interfaces on - different platform, the returned string is only guaranteed - to describe the correct error <em>if format_error/1 is called in the same instance of the erlang virtual machine as the error appeared in</em> (meaning the same operating - system process)!</p> - </note> + parameters are not specified as described here.</p> </desc> </func> </funcs> - <section> - <title>SEE ALSO</title> - <p>erl_driver(4), driver_entry(4)</p> + <title>See Also</title> + <p><seealso marker="erts:erl_driver"><c>erts:erl_driver(4)</c></seealso>, + <seealso marker="erts:driver_entry"><c>erts:driver_entry(4)</c></seealso></p> </section> </erlref> - diff --git a/lib/kernel/doc/src/erl_prim_loader_stub.xml b/lib/kernel/doc/src/erl_prim_loader_stub.xml index f1b2827b37..f3189e2a66 100644 --- a/lib/kernel/doc/src/erl_prim_loader_stub.xml +++ b/lib/kernel/doc/src/erl_prim_loader_stub.xml @@ -37,7 +37,7 @@ The module erl_prim_loader is moved to the runtime system application. Please see <seealso marker="erts:erl_prim_loader">erl_prim_loader(3)</seealso> in the - erts reference manual instead. + ERTS reference manual instead. </p></description> </erlref> diff --git a/lib/kernel/doc/src/erlang_stub.xml b/lib/kernel/doc/src/erlang_stub.xml index 7e8899fdee..afd353e438 100644 --- a/lib/kernel/doc/src/erlang_stub.xml +++ b/lib/kernel/doc/src/erlang_stub.xml @@ -37,7 +37,7 @@ The module erlang is moved to the runtime system application. Please see <seealso marker="erts:erlang">erlang(3)</seealso> in the - erts reference manual instead. + ERTS reference manual instead. </p></description> </erlref> diff --git a/lib/kernel/doc/src/error_handler.xml b/lib/kernel/doc/src/error_handler.xml index 51e283b74f..e5639487dc 100644 --- a/lib/kernel/doc/src/error_handler.xml +++ b/lib/kernel/doc/src/error_handler.xml @@ -31,35 +31,48 @@ <rev></rev> </header> <module>error_handler</module> - <modulesummary>Default System Error Handler</modulesummary> + <modulesummary>Default system error handler.</modulesummary> <description> - <p>The error handler module defines what happens when certain types + <p>This module defines what happens when certain types of errors occur.</p> </description> <funcs> <func> + <name name="raise_undef_exception" arity="3"/> + <fsummary>Raise an undef exception.</fsummary> + <type_desc variable="Args"> + A (possibly empty) list of arguments <c>Arg1,..,ArgN</c> + </type_desc> + <desc> + <p>Raises an <c>undef</c> exception with a stacktrace, indicating + that <c><anno>Module</anno>:<anno>Function</anno>/N</c> is + undefined. + </p> + </desc> + </func> + <func> <name name="undefined_function" arity="3"/> - <fsummary>Called when an undefined function is encountered</fsummary> + <fsummary>Called when an undefined function is encountered.</fsummary> <type_desc variable="Args"> A (possibly empty) list of arguments <c>Arg1,..,ArgN</c> </type_desc> <desc> - <p>This function is called by the run-time system if a call is made to + <p>This function is called by the runtime system if a call is made to <c><anno>Module</anno>:<anno>Function</anno>(Arg1,.., ArgN)</c> and - <c><anno>Module</anno>:<anno>Function</anno>/N</c> is undefined. Note that - <c>undefined_function/3</c> is evaluated inside the process + <c><anno>Module</anno>:<anno>Function</anno>/N</c> is undefined. + Notice that this function is evaluated inside the process making the original call.</p> - <p>This function will first attempt to autoload + <p>This function first attempts to autoload <c><anno>Module</anno></c>. If that is not possible, - an <c>undef</c> exception will be raised.</p> + an <c>undef</c> exception is raised.</p> - <p>If it was possible to load <c><anno>Module</anno></c> - and the function <c><anno>Function</anno>/N</c> is exported, - it will be called.</p> + <p>If it is possible to load <c><anno>Module</anno></c> + and function <c><anno>Function</anno>/N</c> is exported, + it is called.</p> - <p>Otherwise, if the function <c>'$handle_undefined_function'/2</c> - is exported, it will be called as + <p>Otherwise, if function <c>'$handle_undefined_function'/2</c> + is exported, it is called as <c>'$handle_undefined_function'(</c><anno>Function</anno>, <anno>Args</anno>). </p> @@ -67,61 +80,48 @@ <p>Defining <c>'$handle_undefined_function'/2</c> in ordinary application code is highly discouraged. It is very easy to make subtle errors that can take a long time to - debug. Furthermore, none of the tools for static code + debug. Furthermore, none of the tools for static code analysis (such as Dialyzer and Xref) supports the use of <c>'$handle_undefined_function'/2</c> and no such support will be added. Only use this function after having carefully - considered other, less dangerous, solutions. One example of + considered other, less dangerous, solutions. One example of potential legitimate use is creating stubs for other sub-systems during testing and debugging. </p> </warning> - <p>Otherwise an <c>undef</c> exception will be raised.</p> - </desc> - </func> - <func> - <name name="raise_undef_exception" arity="3"/> - <fsummary>Raise an undef exception</fsummary> - <type_desc variable="Args"> - A (possibly empty) list of arguments <c>Arg1,..,ArgN</c> - </type_desc> - <desc> - <p>Raise an <c>undef</c> exception with a stacktrace indicating - that <c><anno>Module</anno>:<anno>Function</anno>/N</c> is - undefined. - </p> + <p>Otherwise an <c>undef</c> exception is raised.</p> </desc> </func> <func> <name name="undefined_lambda" arity="3"/> - <fsummary>Called when an undefined lambda (fun) is encountered</fsummary> + <fsummary>Called when an undefined lambda (fun) is encountered.</fsummary> <type_desc variable="Args"> A (possibly empty) list of arguments <c>Arg1,..,ArgN</c> </type_desc> <desc> <p>This function is evaluated if a call is made to - <c><anno>Fun</anno>(Arg1,.., ArgN)</c> when the module defining the fun is - not loaded. The function is evaluated inside the process + <c><anno>Fun</anno>(Arg1,.., ArgN)</c> when the module defining + the fun is not loaded. The function is evaluated inside the process making the original call.</p> <p>If <c><anno>Module</anno></c> is interpreted, the interpreter is invoked and the return value of the interpreted <c><anno>Fun</anno>(Arg1,.., ArgN)</c> call is returned.</p> <p>Otherwise, it returns, if possible, the value of - <c>apply(<anno>Fun</anno>, <anno>Args</anno>)</c> after an attempt has been made to - autoload <c><anno>Module</anno></c>. If this is not possible, the call - fails with exit reason <c>undef</c>.</p> + <c>apply(<anno>Fun</anno>, <anno>Args</anno>)</c> after an attempt + is made to autoload <c><anno>Module</anno></c>. If this is not possible, + the call fails with exit reason <c>undef</c>.</p> </desc> </func> </funcs> <section> <title>Notes</title> - <p>The code in <c>error_handler</c> is complex and should not be - changed without fully understanding the interaction between + <p>The code in <c>error_handler</c> is complex. Do not + change it without fully understanding the interaction between the error handler, the <c>init</c> process of the code server, and the I/O mechanism of the code.</p> - <p>Changes in the code which may seem small can cause a deadlock - as unforeseen consequences may occur. The use of <c>input</c> is + <p>Code changes that seem small can cause a deadlock, + as unforeseen consequences can occur. The use of <c>input</c> is dangerous in this type of code.</p> </section> </erlref> diff --git a/lib/kernel/doc/src/error_logger.xml b/lib/kernel/doc/src/error_logger.xml index 74830e9d14..a8273e59e2 100644 --- a/lib/kernel/doc/src/error_logger.xml +++ b/lib/kernel/doc/src/error_logger.xml @@ -29,41 +29,44 @@ <rev></rev> </header> <module>error_logger</module> - <modulesummary>Erlang Error Logger</modulesummary> + <modulesummary>Erlang error logger.</modulesummary> <description> <p>The Erlang <em>error logger</em> is an event manager (see <seealso marker="doc/design_principles:des_princ">OTP Design Principles</seealso> and - <seealso marker="stdlib:gen_event">gen_event(3)</seealso>), - registered as <c>error_logger</c>. Error, warning and info events + <seealso marker="stdlib:gen_event"><c>stdlib:gen_event(3)</c></seealso>), + registered as <c>error_logger</c>. Errors, warnings, and info events are sent to the error logger from the Erlang runtime system and the different Erlang/OTP applications. The events are, by default, - logged to tty. Note that an event from a process <c>P</c> is + logged to the terminal. Notice that an event from a process <c>P</c> is logged at the node of the group leader of <c>P</c>. This means that log output is directed to the node from which a process was created, which not necessarily is the same node as where it is executing.</p> - <p>Initially, <c>error_logger</c> only has a primitive event + <p>Initially, <c>error_logger</c> has only a primitive event handler, which buffers and prints the raw event messages. During - system startup, the application Kernel replaces this with a - <em>standard event handler</em>, by default one which writes - nicely formatted output to tty. Kernel can also be configured so - that events are logged to file instead, or not logged at all, see - <seealso marker="kernel_app">kernel(6)</seealso>.</p> - <p>Also the SASL application, if started, adds its own event - handler, which by default writes supervisor, crash and progress - reports to tty. See - <seealso marker="sasl:sasl_app">sasl(6)</seealso>.</p> - <p>It is recommended that user defined applications should report - errors through the error logger, in order to get uniform reports. - User defined event handlers can be added to handle application - specific events. (<c>add_report_handler/1,2</c>). Also, there is - a useful event handler in STDLIB for multi-file logging of events, - see <c>log_mf_h(3)</c>.</p> + system startup, the <c>Kernel</c> application replaces this with a + <em>standard event handler</em>, by default one that writes + nicely formatted output to the terminal. <c>Kernel</c> can also be + configured so that events are logged to a file instead, or not logged at all, + see <seealso marker="kernel_app"><c>kernel(6)</c></seealso>.</p> + <p>Also the <c>SASL</c> application, if started, adds its own event + handler, which by default writes supervisor, crash, and progress + reports to the terminal. See + <seealso marker="sasl:sasl_app"><c>sasl(6)</c></seealso>.</p> + <p>It is recommended that user-defined applications report + errors through the error logger to get uniform reports. + User-defined event handlers can be added to handle application-specific + events, see + <seealso marker="#add_report_handler/1"><c>add_report_handler/1,2</c></seealso>. + Also, a useful event handler is provided in <c>STDLIB</c> for multi-file + logging of events, see + <seealso marker="stdlib:log_mf_h"><c>stdlib:log_mf_h(3)</c></seealso>.</p> <p>Warning events were introduced in Erlang/OTP R9C and are enabled - by default as of 18.0. To retain backwards compatibility with existing - user defined event handlers, these may be tagged as errors or info - using the command line flag <c><![CDATA[+W <e | i | w>]]></c>, thus - showing up as error or info reports in the logs.</p> + by default as from Erlang/OTP 18.0. To retain backwards compatibility + with existing user-defined event handlers, the warning events can be + tagged as <c>errors</c> or <c>info</c> using command-line flag + <c><![CDATA[+W <e | i | w>]]></c>, thus showing up as + <c>ERROR REPORT</c> or <c>INFO REPORT</c> in the logs.</p> </description> <datatypes> <datatype> @@ -72,15 +75,44 @@ </datatypes> <funcs> <func> + <name name="add_report_handler" arity="1"/> + <name name="add_report_handler" arity="2"/> + <fsummary>Add an event handler to the error logger.</fsummary> + <desc> + <p>Adds a new event handler to the error logger. The event + handler must be implemented as a <c>gen_event</c> callback + module, see + <seealso marker="stdlib:gen_event"><c>stdlib:gen_event(3)</c></seealso>.</p> + <p><c><anno>Handler</anno></c> is typically the name of the callback module + and <c><anno>Args</anno></c> is an optional term (defaults to []) passed + to the initialization callback function <c><anno>Handler</anno>:init/1</c>. + The function returns <c>ok</c> if successful.</p> + <p>The event handler must be able to handle the events in this module, see + section <seealso marker="#events">Events</seealso>.</p> + </desc> + </func> + <func> + <name name="delete_report_handler" arity="1"/> + <fsummary>Delete an event handler from the error logger.</fsummary> + <desc> + <p>Deletes an event handler from the error logger by calling + <c>gen_event:delete_handler(error_logger, <anno>Handler</anno>, [])</c>, + see <seealso marker="stdlib:gen_event"><c>stdlib:gen_event(3)</c></seealso>.</p> + </desc> + </func> + <func> <name name="error_msg" arity="1"/> <name name="error_msg" arity="2"/> <name name="format" arity="2"/> - <fsummary>Send an standard error event to the error logger</fsummary> + <fsummary>Send a standard error event to the error logger.</fsummary> <desc> <p>Sends a standard error event to the error logger. - The <c><anno>Format</anno></c> and <c><anno>Data</anno></c> arguments are the same as - the arguments of <c>io:format/2</c>. The event is handled by - the standard event handler.</p> + The <c><anno>Format</anno></c> and <c><anno>Data</anno></c> arguments + are the same as the arguments of + <seealso marker="stdlib:io#format/2"><c>io:format/2</c></seealso> + in <c>STDLIB</c>. + The event is handled by the standard event handler.</p> + <p><em>Example:</em></p> <pre> 1> <input>error_logger:error_msg("An error occurred in ~p~n", [a_module]).</input> @@ -90,16 +122,19 @@ ok</pre> <warning> <p>If called with bad arguments, this function can crash the standard event handler, meaning no further events are - logged. When in doubt, use <c>error_report/1</c> instead.</p> + logged. When in doubt, use + <seealso marker="#error_report/1"><c>error_report/1</c></seealso> + instead.</p> </warning> </desc> </func> <func> <name name="error_report" arity="1"/> - <fsummary>Send a standard error report event to the error logger</fsummary> + <fsummary>Send a standard error report event to the error logger.</fsummary> <desc> <p>Sends a standard error report event to the error logger. The event is handled by the standard event handler.</p> + <p><em>Example:</em></p> <pre> 2> <input>error_logger:error_report([{tag1,data1},a_term,{tag2,data}]).</input> @@ -117,100 +152,27 @@ ok</pre> </func> <func> <name name="error_report" arity="2"/> - <fsummary>Send a user defined error report event to the error logger</fsummary> + <fsummary>Send a user-defined error report event to the error logger.</fsummary> <desc> - <p>Sends a user defined error report event to the error logger. + <p>Sends a user-defined error report event to the error logger. An event handler to handle the event is supposed to have been added. The event is ignored by the standard event handler.</p> <p>It is recommended that <c><anno>Report</anno></c> follows the same - structure as for <c>error_report/1</c>.</p> - </desc> - </func> - <func> - <name name="warning_map" arity="0"/> - <fsummary>Return the current mapping for warning events</fsummary> - <desc> - <p>Returns the current mapping for warning events. Events sent - using <c>warning_msg/1,2</c> or <c>warning_report/1,2</c> - are tagged as errors, warnings (default) or info, depending - on the value of the command line flag <c>+W</c>.</p> - <pre> -os$ <input>erl</input> -Erlang (BEAM) emulator version 5.4.8 [hipe] [threads:0] [kernel-poll] - -Eshell V5.4.8 (abort with ^G) -1> <input>error_logger:warning_map().</input> -warning -2> <input>error_logger:warning_msg("Warnings tagged as: ~p~n", [warning]).</input> - -=WARNING REPORT==== 11-Aug-2005::15:31:55 === -Warnings tagged as: warning -ok -3> -User switch command - --> q -os$ <input>erl +W e</input> -Erlang (BEAM) emulator version 5.4.8 [hipe] [threads:0] [kernel-poll] - -Eshell V5.4.8 (abort with ^G) -1> <input>error_logger:warning_map().</input> -error -2> <input>error_logger:warning_msg("Warnings tagged as: ~p~n", [error]).</input> - -=ERROR REPORT==== 11-Aug-2005::15:31:23 === -Warnings tagged as: error -ok</pre> - </desc> - </func> - <func> - <name name="warning_msg" arity="1"/> - <name name="warning_msg" arity="2"/> - <fsummary>Send a standard warning event to the error logger</fsummary> - <desc> - <p>Sends a standard warning event to the error logger. - The <c><anno>Format</anno></c> and <c><anno>Data</anno></c> arguments are the same as - the arguments of <c>io:format/2</c>. The event is handled by - the standard event handler. It is tagged either as an error, - warning or info, see - <seealso marker="#warning_map/0">warning_map/0</seealso>.</p> - <warning> - <p>If called with bad arguments, this function can crash - the standard event handler, meaning no further events are - logged. When in doubt, use <c>warning_report/1</c> instead.</p> - </warning> - </desc> - </func> - <func> - <name name="warning_report" arity="1"/> - <fsummary>Send a standard warning report event to the error logger</fsummary> - <desc> - <p>Sends a standard warning report event to the error logger. - The event is handled by the standard event handler. It is - tagged either as an error, warning or info, see - <seealso marker="#warning_map/0">warning_map/0</seealso>.</p> - </desc> - </func> - <func> - <name name="warning_report" arity="2"/> - <fsummary>Send a user defined warning report event to the error logger</fsummary> - <desc> - <p>Sends a user defined warning report event to the error - logger. An event handler to handle the event is supposed to - have been added. The event is ignored by the standard event - handler. It is tagged either as an error, warning or info, - depending on the value of - <seealso marker="#warning_map/0">warning_map/0</seealso>.</p> + structure as for + <seealso marker="#error_report/1"><c>error_report/1</c></seealso>.</p> </desc> </func> <func> <name name="info_msg" arity="1"/> <name name="info_msg" arity="2"/> - <fsummary>Send a standard information event to the error logger</fsummary> + <fsummary>Send a standard information event to the error logger.</fsummary> <desc> <p>Sends a standard information event to the error logger. - The <c><anno>Format</anno></c> and <c><anno>Data</anno></c> arguments are the same as - the arguments of <c>io:format/2</c>. The event is handled by - the standard event handler.</p> + The <c><anno>Format</anno></c> and <c><anno>Data</anno></c> arguments + are the same as the arguments of + <seealso marker="stdlib:io#format/2"><c>io:format/2</c></seealso> + in <c>STDLIB</c>. The event is handled by the standard event handler.</p> + <p><em>Example:</em></p> <pre> 1> <input>error_logger:info_msg("Something happened in ~p~n", [a_module]).</input> @@ -226,10 +188,11 @@ ok</pre> </func> <func> <name name="info_report" arity="1"/> - <fsummary>Send a standard information report event to the error logger</fsummary> + <fsummary>Send a standard information report event to the error logger.</fsummary> <desc> <p>Sends a standard information report event to the error logger. The event is handled by the standard event handler.</p> + <p><em>Example:</em></p> <pre> 2> <input>error_logger:info_report([{tag1,data1},a_term,{tag2,data}]).</input> @@ -247,59 +210,22 @@ ok</pre> </func> <func> <name name="info_report" arity="2"/> - <fsummary>Send a user defined information report event to the error logger</fsummary> + <fsummary>Send a user-defined information report event to the error logger.</fsummary> <desc> - <p>Sends a user defined information report event to the error + <p>Sends a user-defined information report event to the error logger. An event handler to handle the event is supposed to have been added. The event is ignored by the standard event handler.</p> <p>It is recommended that <c><anno>Report</anno></c> follows the same - structure as for <c>info_report/1</c>.</p> - </desc> - </func> - <func> - <name name="add_report_handler" arity="1"/> - <name name="add_report_handler" arity="2"/> - <fsummary>Add an event handler to the error logger</fsummary> - <desc> - <p>Adds a new event handler to the error logger. The event - handler must be implemented as a <c>gen_event</c> callback - module, see - <seealso marker="stdlib:gen_event">gen_event(3)</seealso>.</p> - <p><c><anno>Handler</anno></c> is typically the name of the callback module - and <c><anno>Args</anno></c> is an optional term (defaults to []) passed - to the initialization callback function <c><anno>Handler</anno>:init/1</c>. - The function returns <c>ok</c> if successful.</p> - <p>The event handler must be able to handle the - <seealso marker="#events">events</seealso> described below.</p> - </desc> - </func> - <func> - <name name="delete_report_handler" arity="1"/> - <fsummary>Delete an event handler from the error logger</fsummary> - <desc> - <p>Deletes an event handler from the error logger by calling - <c>gen_event:delete_handler(error_logger, <anno>Handler</anno>, [])</c>, - see <seealso marker="stdlib:gen_event">gen_event(3)</seealso>.</p> - </desc> - </func> - <func> - <name name="tty" arity="1"/> - <fsummary>Enable or disable printouts to the tty</fsummary> - <desc> - <p>Enables (<c><anno>Flag</anno> == true</c>) or disables - (<c><anno>Flag</anno> == false</c>) printout of standard events to the tty.</p> - <p>This is done by adding or deleting the standard event handler - for output to tty, thus calling this function overrides - the value of the Kernel <c>error_logger</c> configuration - parameter.</p> + structure as for + <seealso marker="#info_report/1"><c>info_report/1</c></seealso>.</p> </desc> </func> <func> <name name="logfile" arity="1" clause_i="1"/> <name name="logfile" arity="1" clause_i="2"/> <name name="logfile" arity="1" clause_i="3"/> - <fsummary>Enable or disable error printouts to a file</fsummary> + <fsummary>Enable or disable error printouts to a file.</fsummary> <type variable="Filename"/> <type variable="OpenReason" name_i="1"/> <type variable="CloseReason" name_i="2"/> @@ -308,22 +234,22 @@ ok</pre> <desc> <p>Enables or disables printout of standard events to a file.</p> <p>This is done by adding or deleting the standard event handler - for output to file, thus calling this function overrides - the value of the Kernel <c>error_logger</c> configuration + for output to file. Thus, calling this function overrides + the value of the <c>Kernel</c> <c>error_logger</c> configuration parameter.</p> - <p>Enabling file logging can be used in combination with calling - <c>tty(false)</c>, in order to have a silent system, where + <p>Enabling file logging can be used together with calling + <c>tty(false)</c>, to have a silent system where all standard events are logged to a file only. - There can only be one active log file at a time.</p> - <p><c>Request</c> is one of:</p> + Only one log file can be active at a time.</p> + <p><c>Request</c> is one of the following:</p> <taglist> <tag><c>{open, <anno>Filename</anno>}</c></tag> <item> - <p>Opens the log file <c><anno>Filename</anno></c>. Returns <c>ok</c> if + <p>Opens log file <c><anno>Filename</anno></c>. Returns <c>ok</c> if successful, or <c>{error, allready_have_logfile}</c> if logging to file is already enabled, or an error tuple if - another error occurred. For example, if <c><anno>Filename</anno></c> - could not be opened.</p> + another error occurred (for example, if <c><anno>Filename</anno></c> + cannot be opened).</p> </item> <tag><c>close</c></tag> <item> @@ -339,6 +265,97 @@ ok</pre> </taglist> </desc> </func> + <func> + <name name="tty" arity="1"/> + <fsummary>Enable or disable printouts to the terminal.</fsummary> + <desc> + <p>Enables (<c><anno>Flag</anno> == true</c>) or disables + (<c><anno>Flag</anno> == false</c>) printout of standard events + to the terminal.</p> + <p>This is done by adding or deleting the standard event handler + for output to the terminal. Thus, calling this function overrides + the value of the <c>Kernel</c> <c>error_logger</c> configuration parameter.</p> + </desc> + </func> + <func> + <name name="warning_map" arity="0"/> + <fsummary>Return the current mapping for warning events.</fsummary> + <desc> + <p>Returns the current mapping for warning events. Events sent + using <c>warning_msg/1,2</c> or <c>warning_report/1,2</c> + are tagged as errors, warnings (default), or info, depending + on the value of command-line flag <c>+W</c>.</p> + <p><em>Example:</em></p> + <pre> +os$ <input>erl</input> +Erlang (BEAM) emulator version 5.4.8 [hipe] [threads:0] [kernel-poll] + +Eshell V5.4.8 (abort with ^G) +1> <input>error_logger:warning_map().</input> +warning +2> <input>error_logger:warning_msg("Warnings tagged as: ~p~n", [warning]).</input> + +=WARNING REPORT==== 11-Aug-2005::15:31:55 === +Warnings tagged as: warning +ok +3> +User switch command + --> q +os$ <input>erl +W e</input> +Erlang (BEAM) emulator version 5.4.8 [hipe] [threads:0] [kernel-poll] + +Eshell V5.4.8 (abort with ^G) +1> <input>error_logger:warning_map().</input> +error +2> <input>error_logger:warning_msg("Warnings tagged as: ~p~n", [error]).</input> + +=ERROR REPORT==== 11-Aug-2005::15:31:23 === +Warnings tagged as: error +ok</pre> + </desc> + </func> + <func> + <name name="warning_msg" arity="1"/> + <name name="warning_msg" arity="2"/> + <fsummary>Send a standard warning event to the error logger.</fsummary> + <desc> + <p>Sends a standard warning event to the error logger. + The <c><anno>Format</anno></c> and <c><anno>Data</anno></c> arguments + are the same as the arguments of + <seealso marker="stdlib:io#format/2"><c>io:format/2</c></seealso> + in <c>STDLIB</c>. + The event is handled by the standard event handler. It is tagged + as an error, warning, or info, see + <seealso marker="#warning_map/0"><c>warning_map/0</c></seealso>.</p> + <warning> + <p>If called with bad arguments, this function can crash + the standard event handler, meaning no further events are + logged. When in doubt, use <c>warning_report/1</c> instead.</p> + </warning> + </desc> + </func> + <func> + <name name="warning_report" arity="1"/> + <fsummary>Send a standard warning report event to the error logger.</fsummary> + <desc> + <p>Sends a standard warning report event to the error logger. + The event is handled by the standard event handler. It is + tagged as an error, warning, or info, see + <seealso marker="#warning_map/0"><c>warning_map/0</c></seealso>.</p> + </desc> + </func> + <func> + <name name="warning_report" arity="2"/> + <fsummary>Send a user-defined warning report event to the error logger.</fsummary> + <desc> + <p>Sends a user-defined warning report event to the error + logger. An event handler to handle the event is supposed to + have been added. The event is ignored by the standard event + handler. It is tagged as an error, warning, or info, + depending on the value of + <seealso marker="#warning_map/0"><c>warning_map/0</c></seealso>.</p> + </desc> + </func> </funcs> <section> @@ -346,8 +363,8 @@ ok</pre> <title>Events</title> <p>All event handlers added to the error logger must handle the following events. <c>Gleader</c> is the group leader pid of - the process which sent the event, and <c>Pid</c> is the process - which sent the event.</p> + the process that sent the event, and <c>Pid</c> is the process + that sent the event.</p> <taglist> <tag><c>{error, Gleader, {Pid, Format, Data}}</c></tag> <item> @@ -364,18 +381,18 @@ ok</pre> </item> <tag><c>{warning_msg, Gleader, {Pid, Format, Data}}</c></tag> <item> - <p>Generated when <c>warning_msg/1,2</c> is called, provided - that warnings are set to be tagged as warnings.</p> + <p>Generated when <c>warning_msg/1,2</c> is called + if warnings are set to be tagged as warnings.</p> </item> <tag><c>{warning_report, Gleader, {Pid, std_warning, Report}}</c></tag> <item> - <p>Generated when <c>warning_report/1</c> is called, provided - that warnings are set to be tagged as warnings.</p> + <p>Generated when <c>warning_report/1</c> is called + if warnings are set to be tagged as warnings.</p> </item> <tag><c>{warning_report, Gleader, {Pid, Type, Report}}</c></tag> <item> - <p>Generated when <c>warning_report/2</c> is called, provided - that warnings are set to be tagged as warnings.</p> + <p>Generated when <c>warning_report/2</c> is called + if warnings are set to be tagged as warnings.</p> </item> <tag><c>{info_msg, Gleader, {Pid, Format, Data}}</c></tag> <item> @@ -390,17 +407,19 @@ ok</pre> <p>Generated when <c>info_report/2</c> is called.</p> </item> </taglist> - <p>Note that also a number of system internal events may be - received, a catch-all clause last in the definition of + <p>Notice that some system-internal events can also be + received. Therefore a catch-all clause last in the definition of the event handler callback function <c>Module:handle_event/2</c> - is necessary. This also holds true for - <c>Module:handle_info/2</c>, as there are a number of system - internal messages the event handler must take care of as well.</p> + is necessary. This also applies for + <c>Module:handle_info/2</c>, as the event handler must also take care of + some system-internal messages.</p> </section> - <section> - <title>SEE ALSO</title> - <p>gen_event(3), log_mf_h(3), kernel(6), sasl(6)</p> + <title>See Also</title> + <p><seealso marker="stdlib:gen_event"><c>stdlib:gen_event(3)</c></seealso>, + <seealso marker="stdlib:log_mf_h"><c>stdlib:log_mf_h(3)</c></seealso> + <seealso marker="kernel_app"><c>kernel(6)</c></seealso> + <seealso marker="sasl:sasl_app"><c>sasl(6)</c></seealso></p> </section> </erlref> diff --git a/lib/kernel/doc/src/file.xml b/lib/kernel/doc/src/file.xml index bc580dca79..a73038ac58 100644 --- a/lib/kernel/doc/src/file.xml +++ b/lib/kernel/doc/src/file.xml @@ -29,56 +29,57 @@ <rev></rev> </header> <module>file</module> - <modulesummary>File Interface Module</modulesummary> + <modulesummary>File interface module.</modulesummary> <description> - <p>The module <c>file</c> provides an interface to the file system.</p> - <p>On operating systems with thread support, it is possible to let - file operations be performed in threads of their own, allowing + <p>This module provides an interface to the file system.</p> + + <p>On operating systems with thread support, + file operations can be performed in threads of their own, allowing other Erlang processes to continue executing in parallel with - the file operations. See the command line flag - <c>+A</c> in <seealso marker="erts:erl">erl(1)</seealso>.</p> + the file operations. See command-line flag + <c>+A</c> in <seealso marker="erts:erl"><c>erl(1)</c></seealso>.</p> - <p>With regard to file name encoding, the Erlang VM can operate in - two modes. The current mode can be queried using the <seealso - marker="#native_name_encoding">native_name_encoding/0</seealso> - function. It returns either <c>latin1</c> or <c>utf8</c>.</p> + <p>Regarding filename encoding, the Erlang VM can operate in + two modes. The current mode can be queried using function + <seealso marker="#native_name_encoding"><c>native_name_encoding/0</c></seealso>. + It returns <c>latin1</c> or <c>utf8</c>.</p> - <p>In the <c>latin1</c> mode, the Erlang VM does not change the - encoding of file names. In the <c>utf8</c> mode, file names can - contain Unicode characters greater than 255 and the VM will - convert file names back and forth to the native file name encoding + <p>In <c>latin1</c> mode, the Erlang VM does not change the + encoding of filenames. In <c>utf8</c> mode, filenames can + contain Unicode characters greater than 255 and the VM + converts filenames back and forth to the native filename encoding (usually UTF-8, but UTF-16 on Windows).</p> <p>The default mode depends on the operating system. Windows and - MacOS X enforce consistent file name encoding and therefore the - VM uses the <c>utf8</c> mode.</p> + MacOS X enforce consistent filename encoding and therefore the + VM uses <c>utf8</c> mode.</p> - <p>On operating systems with transparent naming (i.e. all Unix - systems except MacOS X), the default will be <c>utf8</c> if the - terminal supports UTF-8, otherwise <c>latin1</c>. The default may - be overridden using the <c>+fnl</c> (to force <c>latin1</c> mode) - or <c>+fnu</c> (to force <c>utf8</c> mode) when starting <seealso - marker="erts:erl">erl</seealso>.</p> + <p>On operating systems with transparent naming (for example, all Unix + systems except MacOS X), default is <c>utf8</c> if the + terminal supports UTF-8, otherwise <c>latin1</c>. The default can + be overridden using <c>+fnl</c> (to force <c>latin1</c> mode) + or <c>+fnu</c> (to force <c>utf8</c> mode) when starting + <seealso marker="erts:erl"><c>erts:erl</c></seealso>.</p> - <p>On operating systems with transparent naming, files could be - inconsistently named, i.e. some files are encoded in UTF-8 while - others are encoded in (for example) iso-latin1. To be able to - handle file systems with inconsistent naming when running in the - <c>utf8</c> mode, the concept of "raw file names" has been - introduced.</p> + <p>On operating systems with transparent naming, files can be + inconsistently named, for example, some files are encoded in UTF-8 while + others are encoded in ISO Latin-1. The concept of <em>raw filenames</em> is + introduced to handle file systems with inconsistent naming when running in + <c>utf8</c> mode.</p> - <p>A raw file name is a file name given as a binary. The Erlang VM - will perform no translation of a file name given as a binary on + <p>A <em>raw filename</em> is a filename specified as a binary. The Erlang VM + does not translate a filename specified as a binary on systems with transparent naming.</p> - <p>When running in the <c>utf8</c> mode, the - <c>file:list_dir/1</c> and <c>file:read_link/1</c> functions will - never return raw file names. Use the <seealso - marker="#list_dir_all">list_dir_all/1</seealso> and <seealso - marker="#read_link_all">read_link_all/1</seealso> functions to - return all file names including raw file names.</p> + <p>When running in <c>utf8</c> mode, functions + <seealso marker="#list_dir/1"><c>list_dir/1</c></seealso> and + <seealso marker="#read_link/1"><c>read_link/1</c></seealso> + never return raw filenames. To return all filenames including raw filenames, + use functions + <seealso marker="#list_dir_all"><c>list_dir_all/1</c></seealso> and + <seealso marker="#read_link_all"><c>read_link_all/1</c></seealso>.</p> - <p>Also see <seealso marker="stdlib:unicode_usage#notes-about-raw-filenames">Notes about raw file names</seealso>.</p> + <p>See also section <seealso marker="stdlib:unicode_usage#notes-about-raw-filenames">Notes About Raw Filenames</seealso> in the <c>STDLIB</c> User´s Giude.</p> </description> @@ -90,8 +91,8 @@ <name>fd()</name> <desc> <p><marker id="type-fd"/> - A file descriptor representing a file opened in <seealso - marker="#raw">raw</seealso> mode.</p> + A file descriptor representing a file opened in + <seealso marker="#raw"><c>raw</c></seealso> mode.</p> </desc> </datatype> <datatype> @@ -104,7 +105,7 @@ <name name="io_device"/> <desc> <p>As returned by - <seealso marker="#open/2">file:open/2</seealso>; + <seealso marker="#open/2"><c>open/2</c></seealso>; <c>pid()</c> is a process handling I/O-protocols.</p> </desc> </datatype> @@ -112,7 +113,7 @@ <name name="name"/> <desc> <p>If VM is in Unicode filename mode, <c>string()</c> and <c>char()</c> - are allowed to be > 255. + are allowed to be > 255. </p> </desc> </datatype> @@ -120,12 +121,12 @@ <name name="name_all"/> <desc> <p>If VM is in Unicode filename mode, <c>string()</c> and <c>char()</c> - are allowed to be > 255. + are allowed to be > 255. <c><anno>RawFilename</anno></c> is a filename not subject to Unicode translation, meaning that it can contain characters not conforming to - the Unicode encoding expected from the filesystem - (i.e. non-UTF-8 characters although the VM is started + the Unicode encoding expected from the file system + (that is, non-UTF-8 characters although the VM is started in Unicode filename mode). </p> </desc> @@ -133,7 +134,7 @@ <datatype> <name name="posix"/> <desc> - <p>An atom which is named from the POSIX error codes used in + <p>An atom that is named from the POSIX error codes used in Unix, and in the runtime libraries of most C compilers.</p> </desc> </datatype> @@ -160,7 +161,7 @@ <funcs> <func> <name name="advise" arity="4"/> - <fsummary>Predeclare an access pattern for file data</fsummary> + <fsummary>Predeclare an access pattern for file data.</fsummary> <type name="posix_file_advise"/> <desc> <p><c>advise/4</c> can be used to announce an intention to access file @@ -171,80 +172,80 @@ </func> <func> <name name="allocate" arity="3"/> - <fsummary>Allocate file space</fsummary> + <fsummary>Allocate file space.</fsummary> <desc> <p><c>allocate/3</c> can be used to preallocate space for a file.</p> - <p>This function only succeeds in platforms that implement this + <p>This function only succeeds in platforms that provide this feature. When it succeeds, space is preallocated for the file but the file size might not be updated. This behaviour depends on the - preallocation implementation. To guarantee the file size is updated - one must truncate the file to the new size.</p> + preallocation implementation. To guarantee that the file size is updated, + truncate the file to the new size.</p> </desc> </func> <func> <name name="change_group" arity="2"/> - <fsummary>Change group of a file</fsummary> + <fsummary>Change group of a file.</fsummary> <desc> <p>Changes group of a file. See - <seealso marker="#write_file_info/2">write_file_info/2</seealso>.</p> + <seealso marker="#write_file_info/2"><c>write_file_info/2</c></seealso>.</p> </desc> </func> <func> <name name="change_mode" arity="2"/> - <fsummary>Change permissions of a file</fsummary> + <fsummary>Change permissions of a file.</fsummary> <desc> <p>Changes permissions of a file. See - <seealso marker="#write_file_info/2">write_file_info/2</seealso>.</p> + <seealso marker="#write_file_info/2"><c>write_file_info/2</c></seealso>.</p> </desc> </func> <func> <name name="change_owner" arity="2"/> - <fsummary>Change owner of a file</fsummary> + <fsummary>Change owner of a file.</fsummary> <desc> <p>Changes owner of a file. See - <seealso marker="#write_file_info/2">write_file_info/2</seealso>.</p> + <seealso marker="#write_file_info/2"><c>write_file_info/2</c></seealso>.</p> </desc> </func> <func> <name name="change_owner" arity="3"/> - <fsummary>Change owner and group of a file</fsummary> + <fsummary>Change owner and group of a file.</fsummary> <desc> <p>Changes owner and group of a file. See - <seealso marker="#write_file_info/2">write_file_info/2</seealso>.</p> + <seealso marker="#write_file_info/2"><c>write_file_info/2</c></seealso>.</p> </desc> </func> <func> <name name="change_time" arity="2"/> - <fsummary>Change the modification time of a file</fsummary> + <fsummary>Change the modification time of a file.</fsummary> <desc> <p>Changes the modification and access times of a file. See - <seealso marker="#write_file_info/2">write_file_info/2</seealso>.</p> + <seealso marker="#write_file_info/2"><c>write_file_info/2</c></seealso>.</p> </desc> </func> <func> <name name="change_time" arity="3"/> - <fsummary>Change the modification and last access time of a file</fsummary> + <fsummary>Change the modification and last access time of a file.</fsummary> <desc> <p>Changes the modification and last access times of a file. See - <seealso marker="#write_file_info/2">write_file_info/2</seealso>.</p> + <seealso marker="#write_file_info/2"><c>write_file_info/2</c></seealso>.</p> </desc> </func> <func> <name name="close" arity="1"/> - <fsummary>Close a file</fsummary> + <fsummary>Close a file.</fsummary> <desc> <p>Closes the file referenced by <c><anno>IoDevice</anno></c>. It mostly - returns <c>ok</c>, expect for some severe errors such as out + returns <c>ok</c>, except for some severe errors such as out of memory.</p> - <p>Note that if the option <c>delayed_write</c> was - used when opening the file, <c>close/1</c> might return an + <p>Notice that if option <c>delayed_write</c> was + used when opening the file, <c>close/1</c> can return an old write error and not even try to close the file. See - <seealso marker="#open/2">open/2</seealso>.</p> + <seealso marker="#open/2"><c>open/2</c></seealso>.</p> </desc> </func> <func> <name name="consult" arity="1"/> - <fsummary>Read Erlang terms from a file</fsummary> + <fsummary>Read Erlang terms from a file.</fsummary> <desc> <p>Reads Erlang terms, separated by '.', from <c><anno>Filename</anno></c>. Returns one of the following:</p> @@ -256,42 +257,44 @@ <tag><c>{error, atom()}</c></tag> <item> <p>An error occurred when opening the file or reading it. - See <seealso marker="#open/2">open/2</seealso> for a list - of typical error codes.</p> + For a list of typical error codes, see + <seealso marker="#open/2"><c>open/2</c></seealso>.</p> </item> <tag><c>{error, {<anno>Line</anno>, <anno>Mod</anno>, <anno>Term</anno>}}</c></tag> <item> <p>An error occurred when interpreting the Erlang terms in - the file. Use <c>format_error/1</c> to convert - the three-element tuple to an English description of - the error.</p> + the file. To convert the three-element tuple to an English + description of the error, use + <seealso marker="#format_error/1"><c>format_error/1</c></seealso>.</p> </item> </taglist> - <p>Example:</p> -<code type="none">f.txt: {person, "kalle", 25}. + <p><em>Example:</em></p> +<code type="none"> +f.txt: {person, "kalle", 25}. {person, "pelle", 30}.</code> -<pre>1> <input>file:consult("f.txt").</input> +<pre> +1> <input>file:consult("f.txt").</input> {ok,[{person,"kalle",25},{person,"pelle",30}]}</pre> - <p>The encoding of of <c><anno>Filename</anno></c> can be set - by a comment as described in <seealso - marker="stdlib:epp#encoding">epp(3)</seealso>.</p> + <p>The encoding of <c><anno>Filename</anno></c> can be set + by a comment, as described in + <seealso marker="stdlib:epp#encoding"><c>stdlib:epp(3)</c></seealso>.</p> </desc> </func> <func> <name name="copy" arity="2"/> <name name="copy" arity="3"/> - <fsummary>Copy file contents</fsummary> + <fsummary>Copy file contents.</fsummary> <desc> <p>Copies <c><anno>ByteCount</anno></c> bytes from <c><anno>Source</anno></c> to <c><anno>Destination</anno></c>. <c><anno>Source</anno></c> and <c><anno>Destination</anno></c> refer - to either filenames or IO devices from e.g. <c>open/2</c>. + to either filenames or IO devices from, for example, <c>open/2</c>. <c><anno>ByteCount</anno></c> defaults to <c>infinity</c>, denoting an infinite number of bytes.</p> - <p>The argument <c><anno>Modes</anno></c> is a list of possible modes, - see <seealso marker="#open/2">open/2</seealso>, and defaults to - [].</p> + <p>Argument <c><anno>Modes</anno></c> is a list of possible modes, + see <seealso marker="#open/2"><c>open/2</c></seealso>, and defaults to + <c>[]</c>.</p> <p>If both <c><anno>Source</anno></c> and <c><anno>Destination</anno></c> refer to filenames, the files are opened with <c>[read, binary]</c> @@ -303,25 +306,51 @@ <p>If <c><anno>Destination</anno></c> refers to a filename, it is opened with <c>write</c> mode prepended to the mode list before the copy, and closed when done.</p> - <p>Returns <c>{ok, <anno>BytesCopied</anno>}</c> where + <p>Returns <c>{ok, <anno>BytesCopied</anno>}</c>, where <c><anno>BytesCopied</anno></c> is - the number of bytes that actually was copied, which may be + the number of bytes that was copied, which can be less than <c><anno>ByteCount</anno></c> if end of file was encountered on the source. If the operation fails, <c>{error, <anno>Reason</anno>}</c> is returned.</p> - <p>Typical error reasons: As for <c>open/2</c> if a file had to - be opened, and as for <c>read/2</c> and <c>write/2</c>.</p> + <p>Typical error reasons: as for + <seealso marker="#open/2"><c>open/2</c></seealso> if a file + had to be opened, and as for + <seealso marker="#read/2"><c>read/2</c></seealso> and + <seealso marker="#write/2"><c>write/2</c></seealso>.</p> + </desc> + </func> + <func> + <name name="datasync" arity="1"/> + <fsummary>Synchronize the in-memory data of a file, ignoring most of its metadata, with that on the physical medium.</fsummary> + <desc> + <p>Ensures that any buffers kept by the operating system + (not by the Erlang runtime system) are written to disk. In + many ways it resembles <c>fsync</c> but it does not update + some of the metadata of the file, such as the access time. On + some platforms this function has no effect.</p> + <p>Applications that access databases or log files often write + a tiny data fragment (for example, one line in a log file) and then + call <c>fsync()</c> immediately to ensure that the written + data is physically stored on the hard disk. Unfortunately, <c>fsync()</c> + always initiates two write operations: one for the newly + written data and another one to update the modification + time stored in the <c>inode</c>. If the modification time is not a part + of the transaction concept, <c>fdatasync()</c> can be used to avoid + unnecessary <c>inode</c> disk write operations.</p> + <p>Available only in some POSIX systems, this call results in a + call to <c>fsync()</c>, or has no effect in systems not providing + the <c>fdatasync()</c> syscall.</p> </desc> </func> <func> <name name="del_dir" arity="1"/> - <fsummary>Delete a directory</fsummary> + <fsummary>Delete a directory.</fsummary> <desc> - <p>Tries to delete the directory <c><anno>Dir</anno></c>. + <p>Tries to delete directory <c><anno>Dir</anno></c>. The directory must be empty before it can be deleted. Returns <c>ok</c> if successful.</p> - <p>Typical error reasons are:</p> + <p>Typical error reasons:</p> <taglist> <tag><c>eacces</c></tag> <item> @@ -351,11 +380,11 @@ </func> <func> <name name="delete" arity="1"/> - <fsummary>Delete a file</fsummary> + <fsummary>Delete a file.</fsummary> <desc> - <p>Tries to delete the file <c><anno>Filename</anno></c>. + <p>Tries to delete file <c><anno>Filename</anno></c>. Returns <c>ok</c> if successful.</p> - <p>Typical error reasons are:</p> + <p>Typical error reasons:</p> <taglist> <tag><c>enoent</c></tag> <item> @@ -367,32 +396,32 @@ </item> <tag><c>eperm</c></tag> <item> - <p>The file is a directory and the user is not super-user.</p> + <p>The file is a directory and the user is not superuser.</p> </item> <tag><c>enotdir</c></tag> <item> - <p>A component of the file name is not a directory. On some + <p>A component of the filename is not a directory. On some platforms, <c>enoent</c> is returned instead.</p> </item> <tag><c>einval</c></tag> <item> - <p><c><anno>Filename</anno></c> had an improper type, such as tuple.</p> + <p><c><anno>Filename</anno></c> has an improper type, such as tuple.</p> </item> </taglist> <warning> - <p>In a future release, a bad type for the - <c><anno>Filename</anno></c> argument will probably generate + <p>In a future release, a bad type for argument + <c><anno>Filename</anno></c> will probably generate an exception.</p> </warning> </desc> </func> <func> <name name="eval" arity="1"/> - <fsummary>Evaluate Erlang expressions in a file</fsummary> + <fsummary>Evaluate Erlang expressions in a file.</fsummary> <desc> <p>Reads and evaluates Erlang expressions, separated by '.' (or - ',', a sequence of expressions is also an expression), from - <c><anno>Filename</anno></c>. The actual result of the evaluation + ',', a sequence of expressions is also an expression) from + <c><anno>Filename</anno></c>. The result of the evaluation is not returned; any expression sequence in the file must be there for its side effect. Returns one of the following:</p> <taglist> @@ -403,35 +432,36 @@ <tag><c>{error, atom()}</c></tag> <item> <p>An error occurred when opening the file or reading it. - See <c>open/2</c> for a list of typical error codes.</p> + For a list of typical error codes, see + <seealso marker="#open/2"><c>open/2</c></seealso>.</p> </item> <tag><c>{error, {<anno>Line</anno>, <anno>Mod</anno>, <anno>Term</anno>}}</c></tag> <item> <p>An error occurred when interpreting the Erlang - expressions in the file. Use <c>format_error/1</c> to - convert the three-element tuple to an English description - of the error.</p> + expressions in the file. To convert the three-element tuple + to an English description of the error, use + <seealso marker="#format_error/1"><c>format_error/1</c></seealso>.</p> </item> </taglist> - <p>The encoding of of <c><anno>Filename</anno></c> can be set - by a comment as described in <seealso - marker="stdlib:epp#encoding">epp(3)</seealso>.</p> + <p>The encoding of <c><anno>Filename</anno></c> can be set + by a comment, as described in + <seealso marker="stdlib:epp#encoding"><c>stdlib:epp(3)</c></seealso>.</p> </desc> </func> <func> <name name="eval" arity="2"/> - <fsummary>Evaluate Erlang expressions in a file</fsummary> + <fsummary>Evaluate Erlang expressions in a file.</fsummary> <desc> - <p>The same as <c>eval/1</c> but the variable bindings - <c><anno>Bindings</anno></c> are used in the evaluation. See - <seealso marker="stdlib:erl_eval">erl_eval(3)</seealso> about - variable bindings.</p> + <p>The same as <c>eval/1</c>, but the variable bindings + <c><anno>Bindings</anno></c> are used in the evaluation. For information + about the variable bindings, see + <seealso marker="stdlib:erl_eval"><c>stdlib:erl_eval(3)</c></seealso>.</p> </desc> </func> <func> <name name="format_error" arity="1"/> - <fsummary>Return a descriptive string for an error reason</fsummary> + <fsummary>Return a descriptive string for an error reason.</fsummary> <desc> <p>Given the error reason returned by any function in this module, returns a descriptive string of the error in English.</p> @@ -439,17 +469,17 @@ </func> <func> <name name="get_cwd" arity="0"/> - <fsummary>Get the current working directory</fsummary> + <fsummary>Get the current working directory.</fsummary> <desc> <p>Returns <c>{ok, <anno>Dir</anno>}</c>, where <c><anno>Dir</anno></c> is the current working directory of the file server.</p> <note> <p>In rare circumstances, this function can fail on Unix. - It may happen if read permission does not exist for + It can occur if read permission does not exist for the parent directories of the current directory.</p> </note> - <p>Typical error reasons are:</p> + <p>A typical error reason:</p> <taglist> <tag><c>eacces</c></tag> <item> @@ -461,17 +491,19 @@ </func> <func> <name name="get_cwd" arity="1"/> - <fsummary>Get the current working directory for the drive specified</fsummary> + <fsummary>Get the current working directory for the specified drive.</fsummary> <desc> - <p><c><anno>Drive</anno></c> should be of the form - "<c>Letter</c><c>:</c>", - for example "c:". Returns <c>{ok, <anno>Dir</anno>}</c> or + <p>Returns <c>{ok, <anno>Dir</anno>}</c> or <c>{error, <anno>Reason</anno>}</c>, where <c><anno>Dir</anno></c> - is the current - working directory of the drive specified.</p> - <p>This function returns <c>{error, enotsup}</c> on platforms - which have no concept of current drive (Unix, for example).</p> - <p>Typical error reasons are:</p> + is the current working directory of the specified drive.</p> + + <p><c><anno>Drive</anno></c> is to be of the form + "<c>Letter</c><c>:</c>", for example, "c:".</p> + + <p>Returns <c>{error, enotsup}</c> on platforms + that have no concept of current drive (Unix, for example).</p> + + <p>Typical error reasons:</p> <taglist> <tag><c>enotsup</c></tag> <item> @@ -490,16 +522,16 @@ </func> <func> <name name="list_dir" arity="1"/> - <fsummary>List files in a directory</fsummary> + <fsummary>List files in a directory.</fsummary> <desc> <p>Lists all files in a directory, <em>except</em> files - with "raw" names. Returns - <c>{ok, <anno>Filenames</anno>}</c> if successful. - Otherwise, it returns <c>{error, <anno>Reason</anno>}</c>. + with raw filenames. Returns + <c>{ok, <anno>Filenames</anno>}</c> if successful, + otherwise <c>{error, <anno>Reason</anno>}</c>. <c><anno>Filenames</anno></c> is a list of the names of all the files in the directory. The names are not sorted.</p> - <p>Typical error reasons are:</p> + <p>Typical error reasons:</p> <taglist> <tag><c>eacces</c></tag> <item> @@ -513,24 +545,24 @@ <tag><c>{no_translation, <anno>Filename</anno>}</c></tag> <item> <p><c><anno>Filename</anno></c> is a <c>binary()</c> with - characters coded in ISO-latin-1 and the VM was started - with the parameter <c>+fnue</c>.</p> + characters coded in ISO Latin-1 and the VM was started + with parameter <c>+fnue</c>.</p> </item> </taglist> </desc> </func> <func> <name name="list_dir_all" arity="1"/> - <fsummary>List all files in a directory</fsummary> + <fsummary>List all files in a directory.</fsummary> <desc> <p><marker id="list_dir_all"/>Lists all the files in a directory, - including files with "raw" names. - Returns <c>{ok, <anno>Filenames</anno>}</c> if successful. - Otherwise, it returns <c>{error, <anno>Reason</anno>}</c>. + including files with raw filenames. + Returns <c>{ok, <anno>Filenames</anno>}</c> if successful, + otherwise <c>{error, <anno>Reason</anno>}</c>. <c><anno>Filenames</anno></c> is a list of the names of all the files in the directory. The names are not sorted.</p> - <p>Typical error reasons are:</p> + <p>Typical error reasons:</p> <taglist> <tag><c>eacces</c></tag> <item> @@ -546,12 +578,12 @@ </func> <func> <name name="make_dir" arity="1"/> - <fsummary>Make a directory</fsummary> + <fsummary>Make a directory.</fsummary> <desc> - <p>Tries to create the directory <c><anno>Dir</anno></c>. Missing parent + <p>Tries to create directory <c><anno>Dir</anno></c>. Missing parent directories are <em>not</em> created. Returns <c>ok</c> if successful.</p> - <p>Typical error reasons are:</p> + <p>Typical error reasons:</p> <taglist> <tag><c>eacces</c></tag> <item> @@ -560,7 +592,7 @@ </item> <tag><c>eexist</c></tag> <item> - <p>There is already a file or directory named <c><anno>Dir</anno></c>.</p> + <p>A file or directory named <c><anno>Dir</anno></c> exists already.</p> </item> <tag><c>enoent</c></tag> <item> @@ -568,7 +600,7 @@ </item> <tag><c>enospc</c></tag> <item> - <p>There is a no space left on the device.</p> + <p>No space is left on the device.</p> </item> <tag><c>enotdir</c></tag> <item> @@ -580,13 +612,13 @@ </func> <func> <name name="make_link" arity="2"/> - <fsummary>Make a hard link to a file</fsummary> + <fsummary>Make a hard link to a file.</fsummary> <desc> <p>Makes a hard link from <c><anno>Existing</anno></c> to - <c><anno>New</anno></c>, on - platforms that support links (Unix and Windows). This function returns - <c>ok</c> if the link was successfully created, or - <c>{error, <anno>Reason</anno>}</c>. On platforms that do not support + <c><anno>New</anno></c> on + platforms supporting links (Unix and Windows). This function returns + <c>ok</c> if the link was successfully created, otherwise + <c>{error, <anno>Reason</anno>}</c>. On platforms not supporting links, <c>{error,enotsup}</c> is returned.</p> <p>Typical error reasons:</p> <taglist> @@ -609,17 +641,16 @@ </func> <func> <name name="make_symlink" arity="2"/> - <fsummary>Make a symbolic link to a file or directory</fsummary> + <fsummary>Make a symbolic link to a file or directory.</fsummary> <desc> - <p>This function creates a symbolic link <c><anno>New</anno></c> to - the file or directory <c><anno>Existing</anno></c>, on platforms that - support symbolic links (most Unix systems and Windows beginning with + <p>Creates a symbolic link <c><anno>New</anno></c> to + the file or directory <c><anno>Existing</anno></c> on platforms + supporting symbolic links (most Unix systems and Windows, beginning with Vista). - <c><anno>Existing</anno></c> need not exist. - This function returns <c>ok</c> if the link was - successfully created, or <c>{error, <anno>Reason</anno>}</c>. - On platforms - that do not support symbolic links, <c>{error, enotsup}</c> + <c><anno>Existing</anno></c> does not need to exist. + Returns <c>ok</c> if the link is + successfully created, otherwise <c>{error, <anno>Reason</anno>}</c>. + On platforms not supporting symbolic links, <c>{error, enotsup}</c> is returned.</p> <p>Typical error reasons:</p> <taglist> @@ -646,23 +677,23 @@ </func> <func> <name name="native_name_encoding" arity="0"/> - <fsummary>Return the VM's configured filename encoding</fsummary> + <fsummary>Return the configured filename encoding of the VM.</fsummary> <desc> - <p><marker id="native_name_encoding"/>This function returns - the file name encoding mode. If it is <c>latin1</c>, the - system does no translation of file names. If it is - <c>utf8</c>, file names will be converted back and forth to - the native file name encoding (usually UTF-8, but UTF-16 on + <p><marker id="native_name_encoding"/>Returns + the filename encoding mode. If it is <c>latin1</c>, the + system translates no filenames. If it is + <c>utf8</c>, filenames are converted back and forth to + the native filename encoding (usually UTF-8, but UTF-16 on Windows).</p> </desc> </func> <func> <name name="open" arity="2"/> - <fsummary>Open a file</fsummary> + <fsummary>Open a file.</fsummary> <desc> - <p>Opens the file <c><anno>File</anno></c> in the mode determined - by <c><anno>Modes</anno></c>, which may contain one or more of the - following items:</p> + <p>Opens file <c><anno>File</anno></c> in the mode determined + by <c><anno>Modes</anno></c>, which can contain one or more of the + following options:</p> <taglist> <tag><c>read</c></tag> <item> @@ -671,98 +702,100 @@ <tag><c>write</c></tag> <item> <p>The file is opened for writing. It is created if it does - not exist. If the file exists, and if <c>write</c> is not - combined with <c>read</c>, the file will be truncated.</p> + not exist. If the file exists and <c>write</c> is not + combined with <c>read</c>, the file is truncated.</p> </item> <tag><c>append</c></tag> <item> - <p>The file will be opened for writing, and it will be - created if it does not exist. Every write operation to a - file opened with <c>append</c> will take place at - the end of the file.</p> + <p>The file is opened for writing. It is created if it does + not exist. Every write operation to a file opened with + <c>append</c> takes place at the end of the file.</p> </item> <tag><c>exclusive</c></tag> <item> - <p>The file, when opened for writing, is created if it - does not exist. If the file exists, open will return - <c>{error, eexist}</c>.</p> + <p>The file is opened for writing. It is created if it does + not exist. If the file exists, <c>{error, eexist}</c> + is returned.</p> <warning><p>This option does not guarantee exclusiveness on - file systems that do not support O_EXCL properly, + file systems not supporting <c>O_EXCL</c> properly, such as NFS. Do not depend on this option unless you know that the file system supports it (in general, local - file systems should be safe).</p></warning> + file systems are safe).</p></warning> </item> <tag><c>raw</c></tag> <item> <p><marker id="raw"/> - The <c>raw</c> option allows faster access to a file, - because no Erlang process is needed to handle the file. + Allows faster access to a file, + as no Erlang process is needed to handle the file. However, a file opened in this way has the following limitations:</p> <list type="bulleted"> - <item>The functions in the <c>io</c> module cannot be used, - because they can only talk to an Erlang process. - Instead, use the <c>read/2</c>, <c>read_line/1</c> and - <c>write/2</c> - functions.</item> - <item>Especially if <c>read_line/1</c> is to be used on a <c>raw</c> file, it is recommended to combine this option with the <c>{read_ahead, Size}</c> option as line oriented I/O is inefficient without buffering.</item> - <item>Only the Erlang process which opened the file can use - it.</item> - <item>A remote Erlang file server cannot be used; - the computer on which the Erlang node is running must + <item><p>The functions in the <c>io</c> module cannot be used, + as they can only talk to an Erlang process. + Instead, use functions + <seealso marker="#read/2"><c>read/2</c></seealso>, + <seealso marker="#read_line/1"><c>read_line/1</c></seealso>, and + <seealso marker="#write/2"><c>write/2</c></seealso>.</p></item> + <item><p>Especially if <c>read_line/1</c> is to be used on a <c>raw</c> + file, it is recommended to combine this option with option + <c>{read_ahead, Size}</c> as line-oriented I/O is inefficient + without buffering.</p></item> + <item><p>Only the Erlang process that opened the file can use + it.</p></item> + <item><p>A remote Erlang file server cannot be used. + The computer on which the Erlang node is running must have access to the file system (directly or through - NFS).</item> + NFS).</p></item> </list> </item> <tag><c>binary</c></tag> <item> - <p>When this option has been given, read operations on the file - will return binaries rather than lists.</p> + <p>Read operations on the file return binaries rather than lists.</p> </item> <tag><c>{delayed_write, Size, Delay}</c></tag> <item> - <p>If this option is used, the data in subsequent - <c>write/2</c> calls is buffered until there are at least - <c>Size</c> bytes buffered, or until the oldest buffered + <p>Data in subsequent + <c>write/2</c> calls is buffered until at least + <c>Size</c> bytes are buffered, or until the oldest buffered data is <c>Delay</c> milliseconds old. Then all buffered data is written in one operating system call. The buffered data is also flushed before some other file operation than <c>write/2</c> is executed.</p> <p>The purpose of this option is to increase performance - by reducing the number of operating system calls, so the - <c>write/2</c> calls should be for sizes significantly - less than <c>Size</c>, and not interspersed by to many - other file operations, for this to happen.</p> + by reducing the number of operating system calls. Thus, the + <c>write/2</c> calls must be for sizes significantly + less than <c>Size</c>, and not interspersed by too many + other file operations.</p> <p>When this option is used, the result of <c>write/2</c> - calls may prematurely be reported as successful, and if - a write error should actually occur the error is - reported as the result of the next file operation, which - is not executed.</p> + calls can prematurely be reported as successful, and if + a write error occurs, the error is reported as the result + of the next file operation, which is not executed.</p> <p>For example, when <c>delayed_write</c> is used, after a - number of <c>write/2</c> calls, <c>close/1</c> might - return <c>{error, enospc}</c> because there was not enough - space on the disc for previously written data, and - <c>close/1</c> should probably be called again since the + number of <c>write/2</c> calls, <c>close/1</c> can + return <c>{error, enospc}</c>, as there is not enough + space on the disc for previously written data. + <c>close/1</c> must probably be called again, as the file is still open.</p> </item> <tag><c>delayed_write</c></tag> <item> <p>The same as <c>{delayed_write, Size, Delay}</c> with reasonable default values for <c>Size</c> and - <c>Delay</c>. (Roughly some 64 KBytes, 2 seconds)</p> + <c>Delay</c> (roughly some 64 KB, 2 seconds).</p> </item> <tag><c>{read_ahead, Size}</c></tag> <item> - <p>This option activates read data buffering. If + <p>Activates read data buffering. If <c>read/2</c> calls are for significantly less than - <c>Size</c> bytes, read operations towards the operating + <c>Size</c> bytes, read operations to the operating system are still performed for blocks of <c>Size</c> bytes. The extra data is buffered and returned in subsequent <c>read/2</c> calls, giving a performance gain - since the number of operating system calls is reduced.</p> - <p>The <c>read_ahead</c> buffer is also highly utilized - by the <c>read_line/1</c> function in <c>raw</c> mode, - why this option is recommended (for performance reasons) + as the number of operating system calls is reduced.</p> + <p>The <c>read_ahead</c> buffer is also highly used + by function <c>read_line/1</c> in <c>raw</c> mode, + therefore this option is recommended + (for performance reasons) when accessing raw files using that function.</p> <p>If <c>read/2</c> calls are for sizes not significantly less than, or even greater than <c>Size</c> bytes, no @@ -771,93 +804,141 @@ <tag><c>read_ahead</c></tag> <item> <p>The same as <c>{read_ahead, Size}</c> with a reasonable - default value for <c>Size</c>. (Roughly some 64 KBytes)</p> + default value for <c>Size</c> (roughly some 64 KB).</p> </item> <tag><c>compressed</c></tag> <item> <p>Makes it possible to read or write gzip compressed - files. The <c>compressed</c> option must be combined - with either <c>read</c> or <c>write</c>, but not both. - Note that the file size obtained with - <c>read_file_info/1</c> will most probably not match the - number of bytes that can be read from a compressed file.</p> + files. Option <c>compressed</c> must be combined + with <c>read</c> or <c>write</c>, but not both. + Notice that the file size obtained with + <seealso marker="#read_file_info/1"><c>read_file_info/1</c></seealso> + does probably not match the number of bytes that can be + read from a compressed file.</p> </item> <tag><c>{encoding, Encoding}</c></tag> <item> - <p>Makes the file perform automatic translation of characters to and from a specific (Unicode) encoding. Note that the data supplied to file:write or returned by file:read still is byte oriented, this option only denotes how data is actually stored in the disk file.</p> - <p>Depending on the encoding, different methods of reading and writing data is preferred. The default encoding of <c>latin1</c> implies using this (the file) module for reading and writing data, as the interfaces provided here work with byte-oriented data, while using other (Unicode) encodings makes the <seealso marker="stdlib:io">io(3)</seealso> module's <c>get_chars</c>, <c>get_line</c> and <c>put_chars</c> functions more suitable, as they can work with the full Unicode range.</p> - <p>If data is sent to an <c>io_device()</c> in a format that cannot be converted to the specified encoding, or if data is read by a function that returns data in a format that cannot cope with the character range of the data, an error occurs and the file will be closed.</p> - <p>The allowed values for <c>Encoding</c> are:</p> + <p>Makes the file perform automatic translation of characters to + and from a specific (Unicode) encoding. Notice that the data supplied + to + <seealso marker="#write/2"><c>write/2</c></seealso> + or returned by + <seealso marker="#read/2"><c>read/2</c></seealso> + still is byte-oriented; this option + denotes only how data is stored in the disk file.</p> + <p>Depending on the encoding, different methods of reading and writing + data is preferred. The default encoding of <c>latin1</c> implies using + this module (<c>file</c>) for reading and writing data as the interfaces + provided here work with byte-oriented data. Using other (Unicode) + encodings makes the + <seealso marker="stdlib:io"><c>stdlib:io(3)</c></seealso> functions + <c>get_chars</c>, <c>get_line</c>, and <c>put_chars</c> more suitable, + as they can work with the full Unicode range.</p> + <p>If data is sent to an <c>io_device()</c> in a format that cannot be + converted to the specified encoding, or if data is read by a function + that returns data in a format that cannot cope with the character range + of the data, an error occurs and the file is closed.</p> + <p>Allowed values for <c>Encoding</c>:</p> <taglist> <tag><c>latin1</c></tag> <item> - <p>The default encoding. Bytes supplied to i.e. file:write are written as is on the file, likewise bytes read from the file are returned to i.e. file:read as is. If the <seealso marker="stdlib:io">io(3)</seealso> module is used for writing, the file can only cope with Unicode characters up to codepoint 255 (the ISO-latin-1 range).</p> + <p>The default encoding. Bytes supplied to the file, that is, + <seealso marker="#write/2"><c>write/2</c></seealso> + are written "as is" on the file. Likewise, bytes read from the file, + that is, + <seealso marker="#read/2"><c>read/2</c></seealso> are + returned "as is". If module + <seealso marker="stdlib:io"><c>stdlib:io(3)</c></seealso> is used for + writing, the file can only cope with Unicode characters up to code point + 255 (the ISO Latin-1 range).</p> </item> - <tag><c>unicode</c> or <c>utf8</c></tag> + <tag><c>unicode or utf8</c></tag> <item> - <p>Characters are translated to and from the UTF-8 encoding before being written to or read from the file. A file opened in this way might be readable using the file:read function, as long as no data stored on the file lies beyond the ISO-latin-1 range (0..255), but failure will occur if the data contains Unicode codepoints beyond that range. The file is best read with the functions in the Unicode aware <seealso marker="stdlib:io">io(3)</seealso> module.</p> - <p>Bytes written to the file by any means are translated to UTF-8 encoding before actually being stored on the disk file.</p> + <p>Characters are translated to and from UTF-8 encoding before they are + written to or read from the file. A file opened in this way can be + readable using function + <seealso marker="#read/2"><c>read/2</c></seealso>, + as long as no data stored on + the file lies beyond the ISO Latin-1 range (0..255), but failure occurs + if the data contains Unicode code points beyond that range. The file is + best read with the functions in the Unicode aware module + <seealso marker="stdlib:io"><c>stdlib:io(3)</c></seealso>.</p> + <p>Bytes written to the file by any means are translated to UTF-8 encoding + before being stored on the disk file.</p> </item> - <tag><c>utf16</c> or <c>{utf16,big}</c></tag> + <tag><c>utf16 or {utf16,big}</c></tag> <item> - <p>Works like <c>unicode</c>, but translation is done to and from big endian UTF-16 instead of UTF-8.</p> + <p>Works like <c>unicode</c>, but translation is done to and from big + endian UTF-16 instead of UTF-8.</p> </item> <tag><c>{utf16,little}</c></tag> <item> - <p>Works like <c>unicode</c>, but translation is done to and from little endian UTF-16 instead of UTF-8.</p> + <p>Works like <c>unicode</c>, but translation is done to and from little + endian UTF-16 instead of UTF-8.</p> </item> - <tag><c>utf32</c> or <c>{utf32,big}</c></tag> + <tag><c>utf32 or {utf32,big}</c></tag> <item> - <p>Works like <c>unicode</c>, but translation is done to and from big endian UTF-32 instead of UTF-8.</p> + <p>Works like <c>unicode</c>, but translation is done to and from big + endian UTF-32 instead of UTF-8.</p> </item> <tag><c>{utf32,little}</c></tag> <item> - <p>Works like <c>unicode</c>, but translation is done to and from little endian UTF-32 instead of UTF-8.</p> + <p>Works like <c>unicode</c>, but translation is done to and from little + endian UTF-32 instead of UTF-8.</p> </item> </taglist> - <p>The Encoding can be changed for a file "on the fly" by using the <seealso marker="stdlib:io#setopts/2">io:setopts/2</seealso> function, why a file can be analyzed in latin1 encoding for i.e. a BOM, positioned beyond the BOM and then be set for the right encoding before further reading.See the <seealso marker="stdlib:unicode">unicode(3)</seealso> module for functions identifying BOM's.</p> + <p>The Encoding can be changed for a file "on the fly" by using function + <seealso marker="stdlib:io#setopts/2"><c>io:setopts/2</c></seealso>. + So a file can be analyzed in latin1 encoding for, for example, a BOM, + positioned beyond the BOM and then be set for the right encoding before + further reading. For functions identifying BOMs, see module + <seealso marker="stdlib:unicode"><c>stdlib:unicode(3)</c></seealso>. </p> <p>This option is not allowed on <c>raw</c> files.</p> </item> <tag><c>ram</c></tag> <item> - <p><c>File</c> must be <c>iodata()</c>. Returns an <c>fd()</c> which lets the <c>file</c> module operate on the data in-memory as if it is a file.</p> + <p><c>File</c> must be <c>iodata()</c>. Returns an <c>fd()</c>, which lets + module <c>file</c> operate on the data in-memory as if it is a file.</p> </item> <tag><c>sync</c></tag> <item> - <p>On platforms that support it, enables the POSIX <c>O_SYNC</c> synchronous I/O flag or its platform-dependent - equivalent (e.g., <c>FILE_FLAG_WRITE_THROUGH</c> on Windows) so that writes to the file block until the data has - been physically written to disk. Be aware, though, that the exact semantics of this flag differ from platform to - platform; for example, neither Linux nor Windows guarantees that all file metadata are also written before the call - returns. For precise semantics, check the details of your platform's documentation. On platforms with no - support for POSIX <c>O_SYNC</c> or equivalent, use of the <c>sync</c> flag causes <c>open</c> to return - <c>{error, enotsup}</c>.</p> + <p>On platforms supporting it, enables the POSIX <c>O_SYNC</c> synchronous + I/O flag or its platform-dependent equivalent (for example, + <c>FILE_FLAG_WRITE_THROUGH</c> on Windows) so that writes to the file + block until the data is physically written to disk. However, be aware + that the exact semantics of this flag differ from platform to + platform. For example, none of Linux or Windows guarantees that all file + metadata are also written before the call returns. For precise semantics, + check the details of your platform documentation. On platforms with no + support for POSIX <c>O_SYNC</c> or equivalent, use of the <c>sync</c> + flag causes <c>open</c> to return <c>{error, enotsup}</c>.</p> </item> </taglist> <p>Returns:</p> <taglist> <tag><c>{ok, <anno>IoDevice</anno>}</c></tag> <item> - <p>The file has been opened in the requested mode. + <p>The file is opened in the requested mode. <c><anno>IoDevice</anno></c> is a reference to the file.</p> </item> <tag><c>{error, <anno>Reason</anno>}</c></tag> <item> - <p>The file could not be opened.</p> + <p>The file cannot be opened.</p> </item> </taglist> - <p><c><anno>IoDevice</anno></c> is really the pid of the process which + <p><c><anno>IoDevice</anno></c> is really the pid of the process that handles the file. This process is linked to the process - which originally opened the file. If any process to which - the <c><anno>IoDevice</anno></c> is linked terminates, the file will - be closed and the process itself will be terminated. + that originally opened the file. If any process to which + the <c><anno>IoDevice</anno></c> is linked terminates, the file is + closed and the process itself is terminated. An <c><anno>IoDevice</anno></c> returned from this call can be used - as an argument to the IO functions (see - <seealso marker="stdlib:io">io(3)</seealso>).</p> + as an argument to the I/O functions (see + <seealso marker="stdlib:io"><c>stdlib:io(3)</c></seealso>).</p> <note> - <p>In previous versions of <c>file</c>, modes were given + <p>In previous versions of <c>file</c>, modes were specified as one of the atoms <c>read</c>, <c>write</c>, or <c>read_write</c> instead of a list. This is still allowed - for reasons of backwards compatibility, but should not be + for reasons of backwards compatibility, but is not to be used for new code. Also note that <c>read_write</c> is not allowed in a mode list.</p> </note> @@ -874,17 +955,17 @@ </item> <tag><c>eisdir</c></tag> <item> - <p>The named file is not a regular file. It may be a - directory, a fifo, or a device.</p> + <p>The named file is not a regular file. It can be a + directory, a FIFO, or a device.</p> </item> <tag><c>enotdir</c></tag> <item> - <p>A component of the file name is not a directory. On some + <p>A component of the filename is not a directory. On some platforms, <c>enoent</c> is returned instead.</p> </item> <tag><c>enospc</c></tag> <item> - <p>There is a no space left on the device (if <c>write</c> + <p>There is no space left on the device (if <c>write</c> access was specified).</p> </item> </taglist> @@ -892,182 +973,186 @@ </func> <func> <name name="path_consult" arity="2"/> - <fsummary>Read Erlang terms from a file</fsummary> + <fsummary>Read Erlang terms from a file.</fsummary> <desc> <p>Searches the path <c><anno>Path</anno></c> (a list of directory names) until the file <c><anno>Filename</anno></c> is found. If <c><anno>Filename</anno></c> is an absolute filename, <c><anno>Path</anno></c> is ignored. - Then reads Erlang terms, separated by '.', from the file. - Returns one of the following:</p> + Then reads Erlang terms, separated by '.', from the file.</p> + <p>Returns one of the following:</p> <taglist> <tag><c>{ok, <anno>Terms</anno>, <anno>FullName</anno>}</c></tag> <item> - <p>The file was successfully read. <c><anno>FullName</anno></c> is + <p>The file is successfully read. <c><anno>FullName</anno></c> is the full name of the file.</p> </item> <tag><c>{error, enoent}</c></tag> <item> - <p>The file could not be found in any of the directories in + <p>The file cannot be found in any of the directories in <c><anno>Path</anno></c>.</p> </item> <tag><c>{error, atom()}</c></tag> <item> <p>An error occurred when opening the file or reading it. - See <seealso marker="#open/2">open/2</seealso> for a list - of typical error codes.</p> + For a list of typical error codes, see + <seealso marker="#open/2"><c>open/2</c></seealso>.</p> </item> <tag><c>{error, {<anno>Line</anno>, <anno>Mod</anno>, <anno>Term</anno>}}</c></tag> <item> <p>An error occurred when interpreting the Erlang terms in - the file. Use <c>format_error/1</c> to convert - the three-element tuple to an English description of + the file. Use + <seealso marker="#format_error/1"><c>format_error/1</c></seealso> + to convert the three-element tuple to an English description of the error.</p> </item> </taglist> - <p>The encoding of of <c><anno>Filename</anno></c> can be set - by a comment as described in <seealso - marker="stdlib:epp#encoding">epp(3)</seealso>.</p> + <p>The encoding of <c><anno>Filename</anno></c> can be set + by a comment as described in + <seealso marker="stdlib:epp#encoding"><c>epp(3)</c></seealso>.</p> </desc> </func> <func> <name name="path_eval" arity="2"/> - <fsummary>Evaluate Erlang expressions in a file</fsummary> + <fsummary>Evaluate Erlang expressions in a file.</fsummary> <desc> <p>Searches the path <c><anno>Path</anno></c> (a list of directory names) until the file <c><anno>Filename</anno></c> is found. - If <c><anno>Filename</anno></c> is an absolute file name, + If <c><anno>Filename</anno></c> is an absolute filename, <c><anno>Path</anno></c> is ignored. Then reads and evaluates Erlang expressions, separated by '.' (or ',', a sequence of expressions is also an expression), from the file. - The actual result of evaluation is not returned; any + The result of evaluation is not returned; any expression sequence in the file must be there for its side - effect. Returns one of the following:</p> + effect.</p> + <p>Returns one of the following:</p> <taglist> <tag><c>{ok, <anno>FullName</anno>}</c></tag> <item> - <p>The file was read and evaluated. <c><anno>FullName</anno></c> is + <p>The file is read and evaluated. <c><anno>FullName</anno></c> is the full name of the file.</p> </item> <tag><c>{error, enoent}</c></tag> <item> - <p>The file could not be found in any of the directories in + <p>The file cannot be found in any of the directories in <c><anno>Path</anno></c>.</p> </item> <tag><c>{error, atom()}</c></tag> <item> <p>An error occurred when opening the file or reading it. - See <seealso marker="#open/2">open/2</seealso> for a list - of typical error codes.</p> + For a list of typical error codes, see + <seealso marker="#open/2"><c>open/2</c></seealso>.</p> </item> <tag><c>{error, {<anno>Line</anno>, <anno>Mod</anno>, <anno>Term</anno>}}</c></tag> <item> <p>An error occurred when interpreting the Erlang - expressions in the file. Use <c>format_error/1</c> to - convert the three-element tuple to an English description + expressions in the file. Use + <seealso marker="#format_error/1"><c>format_error/1</c></seealso> + to convert the three-element tuple to an English description of the error.</p> </item> </taglist> - <p>The encoding of of <c><anno>Filename</anno></c> can be set - by a comment as described in <seealso - marker="stdlib:epp#encoding">epp(3)</seealso>.</p> + <p>The encoding of <c><anno>Filename</anno></c> can be set + by a comment as described in + <seealso marker="stdlib:epp#encoding"><c>stdlib:epp(3)</c></seealso>.</p> </desc> </func> <func> <name name="path_open" arity="3"/> - <fsummary>Open a file</fsummary> + <fsummary>Open a file.</fsummary> <desc> <p>Searches the path <c><anno>Path</anno></c> (a list of directory names) until the file <c><anno>Filename</anno></c> is found. If <c><anno>Filename</anno></c> - is an absolute file name, <c><anno>Path</anno></c> is ignored. - Then opens the file in the mode determined by <c><anno>Modes</anno></c>. - Returns one of the following:</p> + is an absolute filename, <c><anno>Path</anno></c> is ignored. + Then opens the file in the mode determined by <c><anno>Modes</anno></c>.</p> + <p>Returns one of the following:</p> <taglist> <tag><c>{ok, <anno>IoDevice</anno>, <anno>FullName</anno>}</c></tag> <item> - <p>The file has been opened in the requested mode. + <p>The file is opened in the requested mode. <c><anno>IoDevice</anno></c> is a reference to the file and <c><anno>FullName</anno></c> is the full name of the file.</p> </item> <tag><c>{error, enoent}</c></tag> <item> - <p>The file could not be found in any of the directories in + <p>The file cannot be found in any of the directories in <c><anno>Path</anno></c>.</p> </item> <tag><c>{error, atom()}</c></tag> <item> - <p>The file could not be opened.</p> + <p>The file cannot be opened.</p> </item> </taglist> </desc> </func> <func> <name name="path_script" arity="2"/> - <fsummary>Evaluate and return the value of Erlang expressions in a file</fsummary> + <fsummary>Evaluate and return the value of Erlang expressions in a file.</fsummary> <desc> <p>Searches the path <c><anno>Path</anno></c> (a list of directory names) until the file <c><anno>Filename</anno></c> is found. - If <c><anno>Filename</anno></c> is an absolute file name, + If <c><anno>Filename</anno></c> is an absolute filename, <c><anno>Path</anno></c> is ignored. Then reads and evaluates Erlang expressions, separated by '.' (or ',', a - sequence of expressions is also an expression), from the file. - Returns one of the following:</p> + sequence of expressions is also an expression), from the file.</p> + <p>Returns one of the following:</p> <taglist> <tag><c>{ok, <anno>Value</anno>, <anno>FullName</anno>}</c></tag> <item> - <p>The file was read and evaluated. <c><anno>FullName</anno></c> is + <p>The file is read and evaluated. <c><anno>FullName</anno></c> is the full name of the file and <c><anno>Value</anno></c> the value of the last expression.</p> </item> <tag><c>{error, enoent}</c></tag> <item> - <p>The file could not be found in any of the directories in + <p>The file cannot be found in any of the directories in <c><anno>Path</anno></c>.</p> </item> <tag><c>{error, atom()}</c></tag> <item> <p>An error occurred when opening the file or reading it. - See <seealso marker="#open/2">open/2</seealso> for a list - of typical error codes.</p> + For a list of typical error codes, see + <seealso marker="#open/2"><c>open/2</c></seealso>.</p> </item> <tag><c>{error, {<anno>Line</anno>, <anno>Mod</anno>, <anno>Term</anno>}}</c></tag> <item> <p>An error occurred when interpreting the Erlang - expressions in the file. Use <c>format_error/1</c> to - convert the three-element tuple to an English description + expressions in the file. Use + <seealso marker="#format_error/1"><c>format_error/1</c></seealso> + to convert the three-element tuple to an English description of the error.</p> </item> </taglist> - <p>The encoding of of <c><anno>Filename</anno></c> can be set - by a comment as described in <seealso - marker="stdlib:epp#encoding">epp(3)</seealso>.</p> + <p>The encoding of <c><anno>Filename</anno></c> can be set + by a comment as described in + <seealso marker="stdlib:epp#encoding"><c>stdlib:epp(3)</c></seealso>.</p> </desc> </func> <func> <name name="path_script" arity="3"/> - <fsummary>Evaluate and return the value of Erlang expressions in a file</fsummary> + <fsummary>Evaluate and return the value of Erlang expressions in a file.</fsummary> <desc> <p>The same as <c>path_script/2</c> but the variable bindings <c><anno>Bindings</anno></c> are used in the evaluation. See - <seealso marker="stdlib:erl_eval">erl_eval(3)</seealso> about + <seealso marker="stdlib:erl_eval"><c>erl_eval(3)</c></seealso> about variable bindings.</p> </desc> </func> <func> <name name="pid2name" arity="1"/> - <fsummary>Return the name of the file handled by a pid</fsummary> + <fsummary>Return the name of the file handled by a pid.</fsummary> <desc> - <p>If <c><anno>Pid</anno></c> is an IO device, that is, a pid returned from + <p>If <c><anno>Pid</anno></c> is an I/O device, that is, a pid returned from <c>open/2</c>, this function returns the filename, or rather:</p> <taglist> <tag><c>{ok, <anno>Filename</anno>}</c></tag> <item> - <p>If this node's file server is not a slave, the file was - opened by this node's file server, (this implies that + <p>If the file server of this node is not a slave, the file was + opened by the file server of this node (this implies that <c><anno>Pid</anno></c> must be a local pid) and the file is not closed. <c><anno>Filename</anno></c> is the filename in flat string format.</p> @@ -1084,13 +1169,12 @@ </func> <func> <name name="position" arity="2"/> - <fsummary>Set position in a file</fsummary> + <fsummary>Set position in a file.</fsummary> <desc> <p>Sets the position of the file referenced by <c><anno>IoDevice</anno></c> - to <c><anno>Location</anno></c>. Returns - <c>{ok, <anno>NewPosition</anno>}</c> (as - absolute offset) if successful, otherwise - <c>{error, <anno>Reason</anno>}</c>. <c><anno>Location</anno></c> is + to <c><anno>Location</anno></c>. Returns <c>{ok, <anno>NewPosition</anno>}</c> + (as absolute offset) if successful, otherwise + <c>{error, <anno>Reason</anno>}</c>. <c><anno>Location</anno></c> is one of the following:</p> <taglist> <tag><c>Offset</c></tag> @@ -1114,14 +1198,21 @@ <p>The same as above with <c>Offset</c> 0.</p> </item> </taglist> - <p>Note that offsets are counted in bytes, not in characters. If the file is opened using some other <c>encoding</c> than <c>latin1</c>, one byte does not correspond to one character. Positioning in such a file can only be done to known character boundaries, i.e. to a position earlier retrieved by getting a current position, to the beginning/end of the file or to some other position <em>known</em> to be on a correct character boundary by some other means (typically beyond a byte order mark in the file, which has a known byte-size).</p> - <p>Typical error reasons are:</p> + <p>Notice that offsets are counted in bytes, not in characters. If the file + is opened using some other <c>encoding</c> than <c>latin1</c>, one byte + does not correspond to one character. Positioning in such a file can only + be done to known character boundaries. That is, to a position earlier retrieved + by getting a current position, to the beginning/end of the file or to some + other position <em>known</em> to be on a correct character boundary by some + other means (typically beyond a byte order mark in the file, which has a + known byte-size).</p> + <p>A typical error reason is:</p> <taglist> <tag><c>einval</c></tag> <item> - <p>Either <c><anno>Location</anno></c> was illegal, or it + <p>Either <c><anno>Location</anno></c> is illegal, or it is evaluated to a - negative offset in the file. Note that if the resulting + negative offset in the file. Notice that if the resulting position is a negative value, the result is an error, and after the call the file position is undefined.</p> </item> @@ -1130,7 +1221,7 @@ </func> <func> <name name="pread" arity="2"/> - <fsummary>Read from a file at certain positions</fsummary> + <fsummary>Read from a file at certain positions.</fsummary> <desc> <p>Performs a sequence of <c>pread/3</c> in one operation, which is more efficient than calling them one at a time. @@ -1139,70 +1230,94 @@ where each <c><anno>Data</anno></c>, the result of the corresponding <c>pread</c>, is either a list or a binary depending on the mode of the file, or <c>eof</c> if the requested position - was beyond end of file.</p> - <p>As the position is given as a byte-offset, special caution has to be taken when working with files where <c>encoding</c> is set to something else than <c>latin1</c>, as not every byte position will be a valid character boundary on such a file.</p> + is beyond end of file.</p> + <p>As the position is specified as a byte-offset, take special caution + when working with files where <c>encoding</c> is set to something else + than <c>latin1</c>, as not every byte position is a valid character + boundary on such a file.</p> </desc> </func> <func> <name name="pread" arity="3"/> - <fsummary>Read from a file at a certain position</fsummary> + <fsummary>Read from a file at a certain position.</fsummary> <desc> <p>Combines <c>position/2</c> and <c>read/2</c> in one operation, which is more efficient than calling them one at a - time. If <c><anno>IoDevice</anno></c> has been opened in raw mode, - some restrictions apply: <c><anno>Location</anno></c> is only allowed - to be an - integer; and the current position of the file is undefined - after the operation.</p> - <p>As the position is given as a byte-offset, special caution has to be taken when working with files where <c>encoding</c> is set to something else than <c>latin1</c>, as not every byte position will be a valid character boundary on such a file.</p> + time. If <c><anno>IoDevice</anno></c> is opened in <c>raw</c> mode, + some restrictions apply:</p> + <list type="bulleted"> + <item><c><anno>Location</anno></c> is only allowed to be an + integer.</item> + <item>The current position of the file is undefined after the + operation.</item> + </list> + <p>As the position is specified as a byte-offset, take special caution + when working with files where <c>encoding</c> is set to something else + than <c>latin1</c>, as not every byte position is a valid character + boundary on such a file.</p> </desc> </func> <func> <name name="pwrite" arity="2"/> - <fsummary>Write to a file at certain positions</fsummary> + <fsummary>Write to a file at certain positions.</fsummary> <desc> <p>Performs a sequence of <c>pwrite/3</c> in one operation, which is more efficient than calling them one at a time. Returns <c>ok</c> or <c>{error, {<anno>N</anno>, <anno>Reason</anno>}}</c>, where - <c><anno>N</anno></c> is the number of successful writes that was done + <c><anno>N</anno></c> is the number of successful writes done before the failure.</p> - <p>When positioning in a file with other <c>encoding</c> than <c>latin1</c>, caution must be taken to set the position on a correct character boundary, see <seealso marker="#position/2">position/2</seealso> for details.</p> + <p>When positioning in a file with other <c>encoding</c> than <c>latin1</c>, + caution must be taken to set the position on a correct character boundary. + For details, see <seealso marker="#position/2"><c>position/2</c></seealso>.</p> </desc> </func> <func> <name name="pwrite" arity="3"/> - <fsummary>Write to a file at a certain position</fsummary> + <fsummary>Write to a file at a certain position.</fsummary> <desc> <p>Combines <c>position/2</c> and <c>write/2</c> in one operation, which is more efficient than calling them one at a - time. If <c><anno>IoDevice</anno></c> has been opened in raw mode, - some restrictions apply: <c><anno>Location</anno></c> is only allowed - to be an - integer; and the current position of the file is undefined - after the operation.</p> - <p>When positioning in a file with other <c>encoding</c> than <c>latin1</c>, caution must be taken to set the position on a correct character boundary, see <seealso marker="#position/2">position/2</seealso> for details.</p> + time. If <c><anno>IoDevice</anno></c> has been opened in <c>raw</c> mode, + some restrictions apply:</p> + <list type="bulleted"> + <item><c><anno>Location</anno></c> is only allowed to be an + integer.</item> + <item>The current position of the file is undefined after the + operation.</item> + </list> + <p>When positioning in a file with other <c>encoding</c> than <c>latin1</c>, + caution must be taken to set the position on a correct character boundary. + For details, see <seealso marker="#position/2"><c>position/2</c></seealso>.</p> </desc> </func> <func> <name name="read" arity="2"/> - <fsummary>Read from a file</fsummary> + <fsummary>Read from a file.</fsummary> <desc> <p>Reads <c><anno>Number</anno></c> bytes/characters from the file referenced by <c><anno>IoDevice</anno></c>. The functions - <c>read/2</c>, <c>pread/3</c> - and <c>read_line/1</c> are the only ways to read from a file - opened in raw mode (although they work for normally opened - files, too).</p> - <p>For files where <c>encoding</c> is set to something else than <c>latin1</c>, one character might be represented by more than one byte on the file. The parameter <c>Number</c> always denotes the number of <em>characters</em> read from the file, while the position in the file might be moved much more than this number when reading a Unicode file.</p> - <p>Also, if <c>encoding</c> is set to something else than <c>latin1</c>, the <c>read/3</c> call will fail if the data contains characters larger than 255, which is why the <seealso marker="stdlib:io">io(3)</seealso> module is to be preferred when reading such a file.</p> + <seealso marker="#read/2"><c>read/2</c></seealso>, + <seealso marker="#pread/3"><c>pread/3</c></seealso>, and + <seealso marker="#read_line/1"><c>read_line/1</c></seealso> + are the only ways to read from a file opened in <c>raw</c> mode + (although they work for normally opened files, too).</p> + <p>For files where <c>encoding</c> is set to something else than <c>latin1</c>, + one character can be represented by more than one byte on the file. + The parameter <c>Number</c> always denotes the number of <em>characters</em> + read from the file, while the position in the file can be moved much more than + this number when reading a Unicode file.</p> + <p>Also, if <c>encoding</c> is set to something else than <c>latin1</c>, + the <c>read/3</c> call fails if the data contains characters larger than 255, + which is why module <seealso marker="stdlib:io"><c>io(3)</c></seealso> + is to be preferred when reading such a file.</p> <p>The function returns:</p> <taglist> <tag><c>{ok, <anno>Data</anno>}</c></tag> <item> <p>If the file was opened in binary mode, the read bytes are returned in a binary, otherwise in a list. The list or - binary will be shorter than the number of bytes requested + binary is shorter than the number of bytes requested if end of file was reached.</p> </item> <tag><c>eof</c></tag> @@ -1223,14 +1338,16 @@ </item> <tag><c>{no_translation, unicode, latin1}</c></tag> <item> - <p>The file was opened with another <c>encoding</c> than <c>latin1</c> and the data in the file can not be translated to the byte-oriented data that this function returns.</p> + <p>The file is opened with another <c>encoding</c> than <c>latin1</c> and + the data in the file cannot be translated to the byte-oriented data that + this function returns.</p> </item> </taglist> </desc> </func> <func> <name name="read_file" arity="1"/> - <fsummary>Read a file</fsummary> + <fsummary>Read a file.</fsummary> <desc> <p>Returns <c>{ok, <anno>Binary</anno>}</c>, where <c><anno>Binary</anno></c> is a binary @@ -1254,7 +1371,7 @@ </item> <tag><c>enotdir</c></tag> <item> - <p>A component of the file name is not a directory. On some + <p>A component of the filename is not a directory. On some platforms, <c>enoent</c> is returned instead.</p> </item> <tag><c>enomem</c></tag> @@ -1267,34 +1384,38 @@ <func> <name name="read_file_info" arity="1"/> <name name="read_file_info" arity="2"/> - <fsummary>Get information about a file</fsummary> + <fsummary>Retrieve information about a file.</fsummary> <desc> <p>Retrieves information about a file. Returns <c>{ok, <anno>FileInfo</anno>}</c> if successful, otherwise <c>{error, <anno>Reason</anno>}</c>. <c><anno>FileInfo</anno></c> is a record - <c>file_info</c>, defined in the Kernel include file + <c>file_info</c>, defined in the <c>Kernel</c> include file <c>file.hrl</c>. Include the following directive in the module from which the function is called:</p> <code type="none"> --include_lib("kernel/include/file.hrl").</code> - <p>The time type returned in <c>atime</c>, <c>mtime</c> and <c>ctime</c> - is dependent on the time type set in <c>Opts :: {time, Type}</c>. - Type <c>local</c> will return local time, <c>universal</c> will - return universal time and <c>posix</c> will return seconds since - or before unix time epoch which is 1970-01-01 00:00 UTC. - Default is <c>{time, local}</c>. - </p> - <p>If the <c>raw</c> option is set, the file server will not be called - and only informations about local files will be returned.</p> - <note> - <p> - Since file times is stored in posix time on most OS it is - faster to query file information with the <c>posix</c> option. - </p> - </note> + -include_lib("kernel/include/file.hrl").</code> + <p>The time type returned in <c>atime</c>, <c>mtime</c>, and <c>ctime</c> + is dependent on the time type set in <c>Opts :: {time, Type}</c> as + follows:</p> + <taglist> + <tag><c>local</c></tag> + <item><p>Returns local time.</p></item> + <tag><c>universal</c></tag> + <item><p>Returns universal time.</p></item> + <tag><c>posix</c></tag> + <item><p>Returns seconds since or before Unix time epoch, + which is 1970-01-01 00:00 UTC.</p></item> + </taglist> + <p>Default is <c>{time, local}</c>.</p> + <p>If the option <c>raw</c> is set, the file server is not called + and only information about local files is returned.</p> + <note> + <p>As file times are stored in POSIX time on most OS, it is faster to + query file information with option <c>posix</c>.</p> + </note> - <p>The record <c>file_info</c> contains the following fields.</p> + <p>The record <c>file_info</c> contains the following fields:</p> <taglist> <tag><c>size = integer() >= 0</c></tag> <item> @@ -1308,19 +1429,25 @@ <item> <p>The current system access to the file.</p> </item> - <tag><c>atime = </c><seealso marker="#type-date_time">date_time()</seealso><c> | integer() >= 0</c></tag> + <tag><c>atime = </c> + <seealso marker="#type-date_time"><c>date_time()</c></seealso><c> | + integer() >= 0</c></tag> <item> <p>The last time the file was read.</p> </item> - <tag><c>mtime = </c><seealso marker="#type-date_time">date_time()</seealso><c> | integer() >= 0</c></tag> + <tag><c>mtime = </c> + <seealso marker="#type-date_time"><c>date_time()</c></seealso><c> | + integer() >= 0</c></tag> <item> <p>The last time the file was written.</p> </item> - <tag><c>ctime = </c><seealso marker="#type-date_time">date_time()</seealso><c> | integer() >=0</c></tag> + <tag><c>ctime = </c> + <seealso marker="#type-date_time"><c>date_time()</c></seealso><c> | + integer() >=0</c></tag> <item> <p>The interpretation of this time field depends on the operating system. On Unix, it is the last time - the file or the inode was changed. In Windows, it is + the file or the <c>inode</c> was changed. In Windows, it is the create time.</p> </item> <tag><c>mode = integer() >= 0</c></tag> @@ -1328,36 +1455,36 @@ <p>The file permissions as the sum of the following bit values:</p> <taglist> - <tag>8#00400</tag> - <item>read permission: owner</item> - <tag>8#00200</tag> - <item>write permission: owner</item> - <tag>8#00100</tag> - <item>execute permission: owner</item> - <tag>8#00040</tag> - <item>read permission: group</item> - <tag>8#00020</tag> - <item>write permission: group</item> - <tag>8#00010</tag> - <item>execute permission: group</item> - <tag>8#00004</tag> - <item>read permission: other</item> - <tag>8#00002</tag> - <item>write permission: other</item> - <tag>8#00001</tag> - <item>execute permission: other</item> - <tag>16#800</tag> - <item>set user id on execution</item> - <tag>16#400</tag> - <item>set group id on execution</item> + <tag><c>8#00400</c></tag> + <item><p>read permission: owner</p></item> + <tag><c>8#00200</c></tag> + <item><p>write permission: owner</p></item> + <tag><c>8#00100</c></tag> + <item><p>execute permission: owner</p></item> + <tag><c>8#00040</c></tag> + <item><p>read permission: group</p></item> + <tag><c>8#00020</c></tag> + <item><p>write permission: group</p></item> + <tag><c>8#00010</c></tag> + <item><p>execute permission: group</p></item> + <tag><c>8#00004</c></tag> + <item><p>read permission: other</p></item> + <tag><c>8#00002</c></tag> + <item><p>write permission: other</p></item> + <tag><c>8#00001</c></tag> + <item><p>execute permission: other</p></item> + <tag><c>16#800</c></tag> + <item><p>set user id on execution</p></item> + <tag><c>16#400</c></tag> + <item><p>set group id on execution</p></item> </taglist> - <p>On Unix platforms, other bits than those listed above - may be set.</p> + <p>On Unix platforms, the following bits + can also be set:</p> </item> <tag><c>links = integer() >= 0</c></tag> <item> - <p>Number of links to the file (this will always be 1 for - file systems which have no concept of links).</p> + <p>Number of links to the file (this is always 1 for + file systems that have no concept of links).</p> </item> <tag><c>major_device = integer() >= 0</c></tag> <item> @@ -1373,17 +1500,17 @@ <tag><c>inode = integer() >= 0</c></tag> <item> <p>Gives the <c>inode</c> number. On non-Unix file systems, - this field will be zero.</p> + this field is zero.</p> </item> <tag><c>uid = integer() >= 0</c></tag> <item> - <p>Indicates the owner of the file. Will be zero for - non-Unix file systems.</p> + <p>Indicates the owner of the file. On non-Unix file systems, + this field is zero.</p> </item> <tag><c>gid = integer() >= 0</c></tag> <item> <p>Gives the group that the owner of the file belongs to. - Will be zero for non-Unix file systems.</p> + On non-Unix file systems, this field is zero.</p> </item> </taglist> <p>Typical error reasons:</p> @@ -1399,7 +1526,7 @@ </item> <tag><c>enotdir</c></tag> <item> - <p>A component of the file name is not a directory. On some + <p>A component of the filename is not a directory. On some platforms, <c>enoent</c> is returned instead.</p> </item> </taglist> @@ -1407,18 +1534,34 @@ </func> <func> <name name="read_line" arity="1"/> - <fsummary>Read a line from a file</fsummary> + <fsummary>Read a line from a file.</fsummary> <desc> <p>Reads a line of bytes/characters from the file referenced by - <c><anno>IoDevice</anno></c>. Lines are defined to be delimited by the linefeed (LF, <c>\n</c>) character, but any carriage return (CR, <c>\r</c>) followed by a newline is also treated as a single LF character (the carriage return is silently ignored). The line is returned <em>including</em> the LF, but excluding any CR immediately followed by a LF. This behaviour is consistent with the behaviour of <seealso marker="stdlib:io#get_line/2">io:get_line/2</seealso>. If end of file is reached without any LF ending the last line, a line with no trailing LF is returned.</p> - <p>The function can be used on files opened in <c>raw</c> mode. It is however inefficient to use it on <c>raw</c> files if the file is not opened with the option <c>{read_ahead, Size}</c> specified, why combining <c>raw</c> and <c>{read_ahead, Size}</c> is highly recommended when opening a text file for raw line oriented reading.</p> - <p>If <c>encoding</c> is set to something else than <c>latin1</c>, the <c>read_line/1</c> call will fail if the data contains characters larger than 255, why the <seealso marker="stdlib:io">io(3)</seealso> module is to be preferred when reading such a file.</p> + <c><anno>IoDevice</anno></c>. Lines are defined to be delimited by the + linefeed (LF, <c>\n</c>) character, but any carriage return (CR, <c>\r</c>) + followed by a newline is also treated as a single LF character (the carriage + return is silently ignored). The line is returned <em>including</em> the LF, + but excluding any CR immediately followed by an LF. This behaviour is + consistent with the behaviour of + <seealso marker="stdlib:io#get_line/2"><c>io:get_line/2</c></seealso>. + If end of file is reached without any LF ending the last line, a line with no + trailing LF is returned.</p> + <p>The function can be used on files opened in <c>raw</c> mode. However, it is + inefficient to use it on <c>raw</c> files if the file is not opened with + option <c>{read_ahead, Size}</c> specified. Thus, combining <c>raw</c> and + <c>{read_ahead, Size}</c> is highly recommended when opening a text file for + raw line-oriented reading.</p> + <p>If <c>encoding</c> is set to something else than <c>latin1</c>, the + <c>read_line/1</c> call fails if the data contains characters larger than 255, + why module <seealso marker="stdlib:io"><c>stdlib:io(3)</c></seealso> is to be + preferred when reading such a file.</p> <p>The function returns:</p> <taglist> <tag><c>{ok, <anno>Data</anno>}</c></tag> <item> - <p>One line from the file is returned, including the trailing LF, but with CRLF sequences replaced by a single LF (see above).</p> - <p>If the file was opened in binary mode, the read bytes are + <p>One line from the file is returned, including the trailing LF, + but with CRLF sequences replaced by a single LF (see above).</p> + <p>If the file is opened in binary mode, the read bytes are returned in a binary, otherwise in a list.</p> </item> <tag><c>eof</c></tag> @@ -1439,22 +1582,24 @@ </item> <tag><c>{no_translation, unicode, latin1}</c></tag> <item> - <p>The file is was opened with another <c>encoding</c> than <c>latin1</c> and the data on the file can not be translated to the byte-oriented data that this function returns.</p> + <p>The file is opened with another <c>encoding</c> than <c>latin1</c> and + the data on the file cannot be translated to the byte-oriented data that + this function returns.</p> </item> </taglist> </desc> </func> <func> <name name="read_link" arity="1"/> - <fsummary>See what a link is pointing to</fsummary> + <fsummary>See what a link is pointing to.</fsummary> <desc> - <p><marker id="read_link_all"/>This function returns + <p><marker id="read_link_all"/>Returns <c>{ok, <anno>Filename</anno>}</c> if <c><anno>Name</anno></c> refers to a symbolic link that is - not a "raw" file name, or <c>{error, <anno>Reason</anno>}</c> + not a raw filename, or <c>{error, <anno>Reason</anno>}</c> otherwise. On platforms that do not support symbolic links, the return - value will be <c>{error,enotsup}</c>.</p> + value is <c>{error,enotsup}</c>.</p> <p>Typical error reasons:</p> <taglist> <tag><c>einval</c></tag> @@ -1476,14 +1621,14 @@ </func> <func> <name name="read_link_all" arity="1"/> - <fsummary>See what a link is pointing to</fsummary> + <fsummary>See what a link is pointing to.</fsummary> <desc> - <p>This function returns <c>{ok, <anno>Filename</anno>}</c> if + <p>Returns <c>{ok, <anno>Filename</anno>}</c> if <c><anno>Name</anno></c> refers to a symbolic link or <c>{error, <anno>Reason</anno>}</c> otherwise. On platforms that do not support symbolic links, the return - value will be <c>{error,enotsup}</c>.</p> - <p>Note that <c><anno>Filename</anno></c> can be either a list + value is <c>{error,enotsup}</c>.</p> + <p>Notice that <c><anno>Filename</anno></c> can be either a list or a binary.</p> <p>Typical error reasons:</p> <taglist> @@ -1505,31 +1650,30 @@ <func> <name name="read_link_info" arity="1"/> <name name="read_link_info" arity="2"/> - <fsummary>Get information about a link or file</fsummary> + <fsummary>Retrieve information about a link or file.</fsummary> <desc> - <p>This function works like - <seealso marker="#read_file_info/2">read_file_info/1,2</seealso> except that - if <c><anno>Name</anno></c> is a symbolic link, information about - the link will be returned in the <c>file_info</c> record and - the <c>type</c> field of the record will be set to - <c>symlink</c>.</p> - <p>If the <c>raw</c> option is set, the file server will not be called - and only informations about local files will be returned.</p> + <p>Works like + <seealso marker="#read_file_info/2"><c>read_file_info/1,2</c></seealso> + except that if <c><anno>Name</anno></c> is a symbolic link, information + about the link is returned in the <c>file_info</c> record and + the <c>type</c> field of the record is set to <c>symlink</c>.</p> + <p>If the option <c>raw</c> is set, the file server is not called + and only information about local files is returned.</p> <p>If <c><anno>Name</anno></c> is not a symbolic link, this function returns - exactly the same result as <c>read_file_info/1</c>. + the same result as <c>read_file_info/1</c>. On platforms that do not support symbolic links, this function is always equivalent to <c>read_file_info/1</c>.</p> </desc> </func> <func> <name name="rename" arity="2"/> - <fsummary>Rename a file</fsummary> + <fsummary>Rename a file.</fsummary> <desc> <p>Tries to rename the file <c><anno>Source</anno></c> to <c><anno>Destination</anno></c>. It can be used to move files (and directories) between directories, but it is not sufficient to specify - the destination only. The destination file name must also be + the destination only. The destination filename must also be specified. For example, if <c>bar</c> is a normal file and <c>foo</c> and <c>baz</c> are directories, <c>rename("foo/bar", "baz")</c> returns an error, but @@ -1560,7 +1704,7 @@ <item> <p><c><anno>Source</anno></c> is a root directory, or <c><anno>Destination</anno></c> - is a sub-directory of <c><anno>Source</anno></c>.</p> + is a subdirectory of <c><anno>Source</anno></c>.</p> </item> <tag><c>eisdir</c></tag> <item> @@ -1586,58 +1730,105 @@ </func> <func> <name name="script" arity="1"/> - <fsummary>Evaluate and return the value of Erlang expressions in a file</fsummary> + <fsummary>Evaluate and return the value of Erlang expressions in a file.</fsummary> <desc> <p>Reads and evaluates Erlang expressions, separated by '.' (or ',', a sequence of expressions is also an expression), from - the file. Returns one of the following:</p> + the file.</p> + <p>Returns one of the following:</p> <taglist> <tag><c>{ok, <anno>Value</anno>}</c></tag> <item> - <p>The file was read and evaluated. <c><anno>Value</anno></c> is + <p>The file is read and evaluated. <c><anno>Value</anno></c> is the value of the last expression.</p> </item> <tag><c>{error, atom()}</c></tag> <item> <p>An error occurred when opening the file or reading it. - See <seealso marker="#open/2">open/2</seealso> for a list - of typical error codes.</p> + For a list of typical error codes, see + <seealso marker="#open/2"><c>open/2</c></seealso>.</p> </item> <tag><c>{error, {<anno>Line</anno>, <anno>Mod</anno>, <anno>Term</anno>}}</c></tag> <item> <p>An error occurred when interpreting the Erlang - expressions in the file. Use <c>format_error/1</c> to - convert the three-element tuple to an English description + expressions in the file. Use + <seealso marker="#format_error/1"><c>format_error/1</c></seealso> + to convert the three-element tuple to an English description of the error.</p> </item> </taglist> - <p>The encoding of of <c><anno>Filename</anno></c> can be set - by a comment as described in <seealso - marker="stdlib:epp#encoding">epp(3)</seealso>.</p> + <p>The encoding of <c><anno>Filename</anno></c> can be set + by a comment as described in + <seealso marker="stdlib:epp#encoding"><c>epp(3)</c></seealso>.</p> </desc> </func> <func> <name name="script" arity="2"/> - <fsummary>Evaluate and return the value of Erlang expressions in a file</fsummary> + <fsummary>Evaluate and return the value of Erlang expressions in a file.</fsummary> <desc> <p>The same as <c>script/1</c> but the variable bindings <c><anno>Bindings</anno></c> are used in the evaluation. See - <seealso marker="stdlib:erl_eval">erl_eval(3)</seealso> about + <seealso marker="stdlib:erl_eval"><c>erl_eval(3)</c></seealso> about variable bindings.</p> </desc> </func> <func> + <name name="sendfile" arity="2"/> + <fsummary>Send a file to a socket.</fsummary> + <desc> + <p>Sends the file <c>Filename</c> to <c>Socket</c>. + Returns <c>{ok, BytesSent}</c> if successful, + otherwise <c>{error, Reason}</c>.</p> + </desc> + </func> + <func> + <name name="sendfile" arity="5"/> + <fsummary>Send a file to a socket.</fsummary> + <type name="sendfile_option"/> + <desc> + <p>Sends <c>Bytes</c> from the file + referenced by <c>RawFile</c> beginning at <c>Offset</c> to + <c>Socket</c>. + Returns <c>{ok, BytesSent}</c> if successful, + otherwise <c>{error, Reason}</c>. If <c>Bytes</c> is set to + <c>0</c> all data after the specified <c>Offset</c> is sent.</p> + <p>The file used must be opened using the <c>raw</c> flag, and the process + calling <c>sendfile</c> must be the controlling process of the socket. + See <seealso marker="gen_tcp#controlling_process-2"><c>gen_tcp:controlling_process/2</c></seealso>.</p> + <p>If the OS used does not support <c>sendfile</c>, an Erlang fallback + using + <seealso marker="#read/2"><c>read/2</c></seealso> and + <seealso marker="gen_tcp#send/2"><c>gen_tcp:send/2</c></seealso> is used.</p> + <p>The option list can contain the following options:</p> + <taglist> + <tag><c>chunk_size</c></tag> + <item><p>The chunk size used by the Erlang fallback to send + data. If using the fallback, set this to a value + that comfortably fits in the systems memory. Default is 20 MB.</p></item> + <tag><c>use_threads</c></tag> + <item><p>Instructs the emulator to use the <c>async</c> thread pool for the + <c>sendfile</c> system call. This can be useful if the OS you are running + on does not properly support non-blocking <c>sendfile</c> calls. Notice that + using <c>async</c> threads potentially makes your system vulnerable to slow + client attacks. If set to <c>true</c> and no <c>async</c> threads are available, + the <c>sendfile</c> call returns <c>{error,einval}</c>. + Introduced in Erlang/OTP 17.0. Default is <c>false</c>.</p></item> + </taglist> + </desc> + </func> + <func> <name name="set_cwd" arity="1"/> - <fsummary>Set the current working directory</fsummary> + <fsummary>Set the current working directory.</fsummary> <desc> <p>Sets the current working directory of the file server to <c><anno>Dir</anno></c>. Returns <c>ok</c> if successful.</p> - <p>The functions in the <c>file</c> module usually treat binaries - as raw filenames, i.e. they are passed as is even when the encoding - of the binary does not agree with <c>file:native_name_encoding()</c>. - This function however expects binaries to be encoded according to the - value returned by <c>file:native_name_encoding()</c>.</p> + <p>The functions in the module <c>file</c> usually treat binaries + as raw filenames, that is, they are passed "as is" even when the + encoding of the binary does not agree with + <seealso marker="#native_name_encoding"><c>native_name_encoding()</c></seealso>. + However, this function expects binaries to be encoded according to the + value returned by <c>native_name_encoding()</c>.</p> <p>Typical error reasons are:</p> <taglist> <tag><c>enoent</c></tag> @@ -1656,31 +1847,31 @@ </item> <tag><c>badarg</c></tag> <item> - <p><c><anno>Dir</anno></c> had an improper type, + <p><c><anno>Dir</anno></c> has an improper type, such as tuple.</p> </item> <tag><c>no_translation</c></tag> <item> <p><c><anno>Dir</anno></c> is a <c>binary()</c> with characters coded in ISO-latin-1 and the VM is operating - with unicode file name encoding.</p> + with unicode filename encoding.</p> </item> </taglist> <warning> - <p>In a future release, a bad type for the + <p>In a future release, a bad type for argument <c><anno>Dir</anno></c> - argument will probably generate an exception.</p> + will probably generate an exception.</p> </warning> </desc> </func> <func> <name name="sync" arity="1"/> - <fsummary>Synchronizes the in-memory state of a file with that on the physical medium</fsummary> + <fsummary>Synchronize the in-memory state of a file with that on the physical medium.</fsummary> <desc> - <p>Makes sure that any buffers kept by the operating system + <p>Ensures that any buffers kept by the operating system (not by the Erlang runtime system) are written to disk. On some platforms, this function might have no effect.</p> - <p>Typical error reasons are:</p> + <p>A typical error reason is:</p> <taglist> <tag><c>enospc</c></tag> <item> @@ -1690,90 +1881,28 @@ </desc> </func> <func> - <name name="datasync" arity="1"/> - <fsummary>Synchronizes the in-memory data of a file, ignoring most of its metadata, with that on the physical medium</fsummary> - <desc> - <p>Makes sure that any buffers kept by the operating system - (not by the Erlang runtime system) are written to disk. In - many ways it resembles fsync but it does not update - some of the file's metadata such as the access time. On - some platforms this function has no effect.</p> - <p>Applications that access databases or log files often write - a tiny data fragment (e.g., one line in a log file) and then - call fsync() immediately in order to ensure that the written - data is physically stored on the harddisk. Unfortunately, fsync() - will always initiate two write operations: one for the newly - written data and another one in order to update the modification - time stored in the inode. If the modification time is not a part - of the transaction concept, fdatasync() can be used to avoid - unnecessary inode disk write operations.</p> - <p>Available only in some POSIX systems, this call results in a - call to fsync(), or has no effect in systems not implementing - the fdatasync() syscall.</p> - </desc> - </func> - <func> <name name="truncate" arity="1"/> - <fsummary>Truncate a file</fsummary> + <fsummary>Truncate a file.</fsummary> <desc> <p>Truncates the file referenced by <c><anno>IoDevice</anno></c> at - the current position. Returns <c>ok</c> if successful, + the current position. Returns <c>ok</c> if successful, otherwise <c>{error, <anno>Reason</anno>}</c>.</p> </desc> </func> <func> - <name name="sendfile" arity="2"/> - <fsummary>send a file to a socket</fsummary> - <desc> - <p>Sends the file <c>Filename</c> to <c>Socket</c>. - Returns <c>{ok, BytesSent}</c> if successful, - otherwise <c>{error, Reason}</c>.</p> - </desc> - </func> - <func> - <name name="sendfile" arity="5"/> - <fsummary>send a file to a socket</fsummary> - <type name="sendfile_option"/> - <desc> - <p>Sends <c>Bytes</c> from the file - referenced by <c>RawFile</c> beginning at <c>Offset</c> to - <c>Socket</c>. - Returns <c>{ok, BytesSent}</c> if successful, - otherwise <c>{error, Reason}</c>. If <c>Bytes</c> is set to - 0 all data after the given <c>Offset</c> is sent.</p> - <p>The file used must be opened using the raw flag, and the process - calling sendfile must be the controlling process of the socket. - See <seealso marker="gen_tcp#controlling_process-2">gen_tcp:controlling_process/2</seealso></p> - <p>If the OS used does not support sendfile, an Erlang fallback - using file:read and gen_tcp:send is used.</p> - <p>The option list can contain the following options:</p> - <taglist> - <tag><c>chunk_size</c></tag> - <item>The chunk size used by the erlang fallback to send - data. If using the fallback, this should be set to a value - which comfortably fits in the systems memory. Default is 20 MB.</item> - <tag><c>use_threads</c></tag> - <item>Instruct the emulator to use the async thread pool for the - sendfile system call. This could be usefull if the OS you are running - on does not properly support non-blocking sendfile calls. Do note that - using async threads potentially makes your system volnerable to slow - client attacks. If set to true and no async threads are available, - the sendfile call will return <c>{error,einval}</c>. - Introduced in Erlang/OTP 17.0. Default is false.</item> - </taglist> - </desc> - </func> - <func> <name name="write" arity="2"/> - <fsummary>Write to a file</fsummary> + <fsummary>Write to a file.</fsummary> <desc> <p>Writes <c><anno>Bytes</anno></c> to the file referenced by <c><anno>IoDevice</anno></c>. This function is the only way to write to a - file opened in raw mode (although it works for normally - opened files, too). Returns <c>ok</c> if successful, and + file opened in <c>raw</c> mode (although it works for normally opened + files too). Returns <c>ok</c> if successful, and <c>{error, <anno>Reason</anno>}</c> otherwise.</p> - <p>If the file is opened with <c>encoding</c> set to something else than <c>latin1</c>, each byte written might result in several bytes actually being written to the file, as the byte range 0..255 might represent anything between one and four bytes depending on value and UTF encoding type.</p> - <p>Typical error reasons are:</p> + <p>If the file is opened with <c>encoding</c> set to something else than + <c>latin1</c>, each byte written can result in many bytes being written to + the file, as the byte range 0..255 can represent anything between one and + four bytes depending on value and UTF encoding type.</p> + <p>Typical error reasons:</p> <taglist> <tag><c>ebadf</c></tag> <item> @@ -1781,34 +1910,35 @@ </item> <tag><c>enospc</c></tag> <item> - <p>There is a no space left on the device.</p> + <p>No space is left on the device.</p> </item> </taglist> </desc> </func> <func> <name name="write_file" arity="2"/> - <fsummary>Write a file</fsummary> + <fsummary>Write a file.</fsummary> <desc> - <p>Writes the contents of the iodata term <c><anno>Bytes</anno></c> - to the file <c><anno>Filename</anno></c>. - The file is created if it does not - exist. If it exists, the previous contents are - overwritten. Returns <c>ok</c>, or <c>{error, <anno>Reason</anno>}</c>.</p> - <p>Typical error reasons are:</p> + <p>Writes the contents of the <c>iodata</c> term <c><anno>Bytes</anno></c> + to file <c><anno>Filename</anno></c>. + The file is created if it does not exist. + If it exists, the previous contents are overwritten. + Returns <c>ok</c> if successful, otherwise + <c>{error, <anno>Reason</anno>}</c>.</p> + <p>Typical error reasons:</p> <taglist> <tag><c>enoent</c></tag> <item> - <p>A component of the file name does not exist.</p> + <p>A component of the filename does not exist.</p> </item> <tag><c>enotdir</c></tag> <item> - <p>A component of the file name is not a directory. On some + <p>A component of the filename is not a directory. On some platforms, <c>enoent</c> is returned instead.</p> </item> <tag><c>enospc</c></tag> <item> - <p>There is a no space left on the device.</p> + <p>No space is left on the device.</p> </item> <tag><c>eacces</c></tag> <item> @@ -1824,51 +1954,64 @@ </func> <func> <name name="write_file" arity="3"/> - <fsummary>Write a file</fsummary> + <fsummary>Write a file.</fsummary> <desc> <p>Same as <c>write_file/2</c>, but takes a third argument <c><anno>Modes</anno></c>, a list of possible modes, see - <seealso marker="#open/2">open/2</seealso>. The mode flags - <c>binary</c> and <c>write</c> are implicit, so they should - not be used.</p> + <seealso marker="#open/2"><c>open/2</c></seealso>. The mode flags + <c>binary</c> and <c>write</c> are implicit, so they are + not to be used.</p> </desc> </func> <func> <name name="write_file_info" arity="2"/> <name name="write_file_info" arity="3"/> - <fsummary>Change information about a file</fsummary> + <fsummary>Change file information.</fsummary> <desc> - <p>Change file information. Returns <c>ok</c> if successful, + <p>Changes file information. Returns <c>ok</c> if successful, otherwise <c>{error, <anno>Reason</anno>}</c>. <c><anno>FileInfo</anno></c> is a record - <c>file_info</c>, defined in the Kernel include file + <c>file_info</c>, defined in the <c>Kernel</c> include file <c>file.hrl</c>. Include the following directive in the module from which the function is called:</p> <code type="none"> --include_lib("kernel/include/file.hrl").</code> - <p>The time type set in <c>atime</c>, <c>mtime</c> and <c>ctime</c> - is dependent on the time type set in <c>Opts :: {time, Type}</c>. - Type <c>local</c> will interpret the time set as local, <c>universal</c> will - interpret it as universal time and <c>posix</c> must be seconds since - or before unix time epoch which is 1970-01-01 00:00 UTC. - Default is <c>{time, local}</c>.</p> - <p>If the <c>raw</c> option is set, the file server will not be called - and only informations about local files will be returned.</p> + -include_lib("kernel/include/file.hrl").</code> + <p>The time type set in <c>atime</c>, <c>mtime</c>, and <c>ctime</c> + depends on the time type set in <c>Opts :: {time, Type}</c> as + follows:</p> + <taglist> + <tag><c>local</c></tag> + <item><p>Interprets the time set as local.</p></item> + <tag><c>universal</c></tag> + <item><p>Interprets it as universal time.</p></item> + <tag><c>posix</c></tag> + <item><p>Must be seconds since or before Unix time epoch, + which is 1970-01-01 00:00 UTC.</p></item> + </taglist> + <p>Default is <c>{time, local}</c>.</p> + <p>If the option <c>raw</c> is set, the file server is not called + and only information about local files is returned.</p> <p>The following fields are used from the record, if they are - given.</p> + specified:</p> <taglist> - <tag><c>atime = </c><seealso marker="#type-date_time">date_time()</seealso><c> | integer() >= 0</c></tag> + <tag><c>atime = </c> + <seealso marker="#type-date_time"><c>date_time()</c></seealso><c> | + integer() >= 0</c></tag> <item> <p>The last time the file was read.</p> </item> - <tag><c>mtime = </c><seealso marker="#type-date_time">date_time()</seealso><c> | integer() >= 0</c></tag> + <tag><c>mtime = </c> + <seealso marker="#type-date_time"><c>date_time()</c></seealso><c> | + integer() >= 0</c></tag> <item> <p>The last time the file was written.</p> </item> - <tag><c>ctime = </c><seealso marker="#type-date_time">date_time()</seealso><c> | integer() >= 0</c></tag> + <tag><c>ctime = </c> + <seealso marker="#type-date_time"><c>date_time()</c></seealso><c> | + integer() >= 0</c></tag> <item> - <p>On Unix, any value give for this field will be ignored - (the "ctime" for the file will be set to the current + <p>On Unix, any value specified for this field is ignored + (the "ctime" for the file is set to the current time). On Windows, this field is the new creation time to set for the file.</p> </item> @@ -1877,40 +2020,40 @@ <p>The file permissions as the sum of the following bit values:</p> <taglist> - <tag>8#00400</tag> - <item>read permission: owner</item> - <tag>8#00200</tag> - <item>write permission: owner</item> - <tag>8#00100</tag> - <item>execute permission: owner</item> - <tag>8#00040</tag> - <item>read permission: group</item> - <tag>8#00020</tag> - <item>write permission: group</item> - <tag>8#00010</tag> - <item>execute permission: group</item> - <tag>8#00004</tag> - <item>read permission: other</item> - <tag>8#00002</tag> - <item>write permission: other</item> - <tag>8#00001</tag> - <item>execute permission: other</item> - <tag>16#800</tag> - <item>set user id on execution</item> - <tag>16#400</tag> - <item>set group id on execution</item> + <tag><c>8#00400</c></tag> + <item><p>Read permission: owner</p></item> + <tag><c>8#00200</c></tag> + <item><p>Write permission: owner</p></item> + <tag><c>8#00100</c></tag> + <item><p>Execute permission: owner</p></item> + <tag><c>8#00040</c></tag> + <item><p>Read permission: group</p></item> + <tag><c>8#00020</c></tag> + <item><p>Write permission: group</p></item> + <tag><c>8#00010</c></tag> + <item><p>Execute permission: group</p></item> + <tag><c>8#00004</c></tag> + <item><p>Read permission: other</p></item> + <tag><c>8#00002</c></tag> + <item><p>Write permission: other</p></item> + <tag><c>8#00001</c></tag> + <item><p>Execute permission: other</p></item> + <tag><c>16#800</c></tag> + <item><p>Set user id on execution</p></item> + <tag><c>16#400</c></tag> + <item><p>Set group id on execution</p></item> </taglist> - <p>On Unix platforms, other bits than those listed above - may be set.</p> + <p>On Unix platforms, the following bits + can also be set.</p> </item> <tag><c>uid = integer() >= 0</c></tag> <item> - <p>Indicates the owner of the file. Ignored for non-Unix + <p>Indicates the file owner. Ignored for non-Unix file systems.</p> </item> <tag><c>gid = integer() >= 0</c></tag> <item> - <p>Gives the group that the owner of the file belongs to. + <p>Gives the group that the file owner belongs to. Ignored for non-Unix file systems.</p> </item> </taglist> @@ -1927,7 +2070,7 @@ </item> <tag><c>enotdir</c></tag> <item> - <p>A component of the file name is not a directory. On some + <p>A component of the filename is not a directory. On some platforms, <c>enoent</c> is returned instead.</p> </item> </taglist> @@ -1938,77 +2081,82 @@ <section> <title>POSIX Error Codes</title> <list type="bulleted"> - <item><c>eacces</c> - permission denied</item> - <item><c>eagain</c> - resource temporarily unavailable</item> - <item><c>ebadf</c> - bad file number</item> - <item><c>ebusy</c> - file busy</item> - <item><c>edquot</c> - disk quota exceeded</item> - <item><c>eexist</c> - file already exists</item> - <item><c>efault</c> - bad address in system call argument</item> - <item><c>efbig</c> - file too large</item> - <item><c>eintr</c> - interrupted system call</item> - <item><c>einval</c> - invalid argument</item> - <item><c>eio</c> - IO error</item> - <item><c>eisdir</c> - illegal operation on a directory</item> - <item><c>eloop</c> - too many levels of symbolic links</item> - <item><c>emfile</c> - too many open files</item> - <item><c>emlink</c> - too many links</item> - <item><c>enametoolong</c> - file name too long</item> - <item><c>enfile</c> - file table overflow</item> - <item><c>enodev</c> - no such device</item> - <item><c>enoent</c> - no such file or directory</item> - <item><c>enomem</c> - not enough memory</item> - <item><c>enospc</c> - no space left on device</item> - <item><c>enotblk</c> - block device required</item> - <item><c>enotdir</c> - not a directory</item> - <item><c>enotsup</c> - operation not supported</item> - <item><c>enxio</c> - no such device or address</item> - <item><c>eperm</c> - not owner</item> - <item><c>epipe</c> - broken pipe</item> - <item><c>erofs</c> - read-only file system</item> - <item><c>espipe</c> - invalid seek</item> - <item><c>esrch</c> - no such process</item> - <item><c>estale</c> - stale remote file handle</item> - <item><c>exdev</c> - cross-domain link</item> + <item><c>eacces</c> - Permission denied</item> + <item><c>eagain</c> - Resource temporarily unavailable</item> + <item><c>ebadf</c> - Bad file number</item> + <item><c>ebusy</c> - File busy</item> + <item><c>edquot</c> - Disk quota exceeded</item> + <item><c>eexist</c> - File already exists</item> + <item><c>efault</c> - Bad address in system call argument</item> + <item><c>efbig</c> - File too large</item> + <item><c>eintr</c> - Interrupted system call</item> + <item><c>einval</c> - Invalid argument</item> + <item><c>eio</c> - I/O error</item> + <item><c>eisdir</c> - Illegal operation on a directory</item> + <item><c>eloop</c> - Too many levels of symbolic links</item> + <item><c>emfile</c> - Too many open files</item> + <item><c>emlink</c> - Too many links</item> + <item><c>enametoolong</c> - Filename too long</item> + <item><c>enfile</c> - File table overflow</item> + <item><c>enodev</c> - No such device</item> + <item><c>enoent</c> - No such file or directory</item> + <item><c>enomem</c> - Not enough memory</item> + <item><c>enospc</c> - No space left on device</item> + <item><c>enotblk</c> - Block device required</item> + <item><c>enotdir</c> - Not a directory</item> + <item><c>enotsup</c> - Operation not supported</item> + <item><c>enxio</c> - No such device or address</item> + <item><c>eperm</c> - Not owner</item> + <item><c>epipe</c> - Broken pipe</item> + <item><c>erofs</c> - Read-only file system</item> + <item><c>espipe</c> - Invalid seek</item> + <item><c>esrch</c> - No such process</item> + <item><c>estale</c> - Stale remote file handle</item> + <item><c>exdev</c> - Cross-domain link</item> </list> </section> <section> <title>Performance</title> - <p>Some operating system file operations, for example a - <c>sync/1</c> or <c>close/1</c> on a huge file, may block their - calling thread for seconds. If this befalls the emulator main + <p>Some operating system file operations, for example, a + <c>sync/1</c> or <c>close/1</c> on a huge file, can block their + calling thread for seconds. If this affects the emulator main thread, the response time is no longer in the order of milliseconds, depending on the definition of "soft" in soft real-time system.</p> <p>If the device driver thread pool is active, file operations are done through those threads instead, so the emulator can go on executing Erlang processes. Unfortunately, the time for serving a - file operation increases due to the extra scheduling required + file operation increases because of the extra scheduling required from the operating system.</p> <p>If the device driver thread pool is disabled or of size 0, large - file reads and writes are segmented into several smaller, which - enables the emulator so server other processes during the file - operation. This gives the same effect as when using the thread + file reads and writes are segmented into many smaller, which + enable the emulator to serve other processes during the file + operation. This has the same effect as when using the thread pool, but with larger overhead. Other file operations, for - example <c>sync/1</c> or <c>close/1</c> on a huge file, still are + example, <c>sync/1</c> or <c>close/1</c> on a huge file, still are a problem.</p> <p>For increased performance, raw files are recommended. Raw files - uses the file system of the node's host machine. For normal files - (non-raw), the file server is used to find the files, and if - the node is running its file server as slave to another node's, - and the other node runs on some other host machine, they may have - different file systems. This is seldom a problem, but you have - now been warned.</p> - <p>A normal file is really a process so it can be used as an IO - device (see <c>io</c>). Therefore when data is written to a + use the file system of the host machine of the node.</p> + <note> + <p> + For normal files (non-raw), the file server is used to find the files, + and if the node is running its file server as slave to the file server + of another node, and the other node runs on some other host machine, + they can have different file systems. + However, this is seldom a problem.</p> + </note> + <p>A normal file is really a process so it can be used as an I/O + device (see + <seealso marker="stdlib:io"><c>io</c></seealso>). + Therefore, when data is written to a normal file, the sending of the data to the file process, copies all data that are not binaries. Opening the file in binary mode and writing binaries is therefore recommended. If the file is opened on another node, or if the file server runs as slave to - another node's, also binaries are copied.</p> + the file server of another node, also binaries are copied.</p> <p>Caching data to reduce the number of file operations, or rather - the number of calls to the file driver, will generally increase + the number of calls to the file driver, generally increases performance. The following function writes 4 MBytes in 23 seconds when tested:</p> <code type="none"><![CDATA[ @@ -2023,10 +2171,12 @@ create_file_slow(FD, M, M) -> create_file_slow(FD, M, N) -> ok = file:write(FD, <<M:32/unsigned>>), create_file_slow(FD, M+1, N).]]></code> + <p>The following, functionally equivalent, function collects 1024 entries into a list of 128 32-byte binaries before each call to - <c>file:write/2</c> and so does the same work in 0.52 seconds, - which is 44 times faster.</p> + <seealso marker="#write/2"><c>write/2</c></seealso> and so + does the same work in 0.52 seconds, + which is 44 times faster:</p> <code type="none"><![CDATA[ create_file(Name, N) when integer(N), N >= 0 -> {ok, FD} = file:open(Name, [raw, write, delayed_write, binary]), @@ -2055,61 +2205,62 @@ create_file(FD, M, N0, R) when M + 8 =< N0 -> create_file(FD, M, N0, R) -> N1 = N0-1, create_file(FD, M, N1, [<<N1:32/unsigned>> | R]).]]></code> + <note> <p>Trust only your own benchmarks. If the list length in - <c>create_file/2</c> above is increased, it will run slightly - faster, but consume more memory and cause more memory + <c>create_file/2</c> above is increased, it runs slightly + faster, but consumes more memory and causes more memory fragmentation. How much this affects your application is - something that this simple benchmark can not predict.</p> - <p>If the size of each binary is increased to 64 bytes, it will - also run slightly faster, but the code will be twice as clumsy. - In the current implementation are binaries larger than 64 bytes + something that this simple benchmark cannot predict.</p> + <p>If the size of each binary is increased to 64 bytes, it + also runs slightly faster, but the code is then twice as clumsy. + In the current implementation, binaries larger than 64 bytes are stored in memory common to all processes and not copied when sent between processes, while these smaller binaries are stored on the process heap and copied when sent like any other term.</p> - <p>So, with a binary size of 68 bytes <c>create_file/2</c> runs - 30 percent slower then with 64 bytes, and will cause much more - memory fragmentation. Note that if the binaries were to be sent - between processes (for example a non-raw file) the results + <p>So, with a binary size of 68 bytes, <c>create_file/2</c> runs + 30 percent slower than with 64 bytes, and causes much more + memory fragmentation. Notice that if the binaries were to be sent + between processes (for example, a non-raw file), the results would probably be completely different.</p> </note> <p>A raw file is really a port. When writing data to a port, it is - efficient to write a list of binaries. There is no need to + efficient to write a list of binaries. It is not needed to flatten a deep list before writing. On Unix hosts, scatter output, which writes a set of buffers in one operation, is used when - possible. In this way <c>file:write(FD, [Bin1, Bin2 | Bin3])</c> - will write the contents of the binaries without copying the data - at all except for perhaps deep down in the operating system + possible. In this way <c>write(FD, [Bin1, Bin2 | Bin3])</c> + writes the contents of the binaries without copying the data + at all, except for perhaps deep down in the operating system kernel.</p> <p>For raw files, <c>pwrite/2</c> and <c>pread/2</c> are efficiently implemented. The file driver is called only once for the whole operation, and the list iteration is done in the file driver.</p> <p>The options <c>delayed_write</c> and <c>read_ahead</c> to - <c>file:open/2</c> makes the file driver cache data to reduce + <seealso marker="#open/2"><c>open/2</c></seealso> + make the file driver cache data to reduce the number of operating system calls. The function - <c>create_file/2</c> in the example above takes 60 seconds - seconds without the <c>delayed_write</c> option, which is 2.6 + <c>create_file/2</c> in the recent example takes 60 seconds + without option <c>delayed_write</c>, which is 2.6 times slower.</p> - <p>And, as a really bad example, <c>create_file_slow/2</c> above - without the <c>raw</c>, <c>binary</c> and <c>delayed_write</c> - options, that is it calls <c>file:open(Name, [write])</c>, needs + <p>As a bad example, <c>create_file_slow/2</c> + without options <c>raw</c>, <c>binary</c>, and <c>delayed_write</c>, + meaning it calls <c>open(Name, [write])</c>, needs 1 min 20 seconds for the job, which is 3.5 times slower than the first example, and 150 times slower than the optimized - <c>create_file/2</c>. </p> - </section> - - <section> - <title>Warnings</title> - <p>If an error occurs when accessing an open file with the <c>io</c> - module, the process which handles the file will exit. The dead - file process might hang if a process tries to access it later. + <c>create_file/2</c>.</p> + <warning> + <p>If an error occurs when accessing an open file with module + <seealso marker="stdlib:io"><c>io</c></seealso>, + the process handling the file exits. The dead + file process can hang if a process tries to access it later. This will be fixed in a future release.</p> + </warning> </section> <section> - <title>SEE ALSO</title> - <p><seealso marker="stdlib:filename">filename(3)</seealso></p> + <title>See Also</title> + <p><seealso marker="stdlib:filename"><c>filename(3)</c></seealso></p> </section> </erlref> diff --git a/lib/kernel/doc/src/gen_sctp.xml b/lib/kernel/doc/src/gen_sctp.xml index 3a50d4cbe0..57307cd594 100644 --- a/lib/kernel/doc/src/gen_sctp.xml +++ b/lib/kernel/doc/src/gen_sctp.xml @@ -30,68 +30,60 @@ <checked></checked> <date>2007-03-21</date> <rev>A</rev> - <file>gen_sctp.sgml</file> + <file>gen_sctp.xml</file> </header> <module>gen_sctp</module> - <modulesummary>The gen_sctp module provides functions for communicating with sockets using the SCTP protocol.</modulesummary> + <modulesummary>Functions for communicating with sockets using the SCTP + protocol.</modulesummary> <description> - <p>The <c>gen_sctp</c> module provides functions for communicating with + <p>This module provides functions for communicating with sockets using the SCTP protocol. The implementation assumes that the OS kernel supports SCTP - <url href="http://www.rfc-archive.org/getrfc.php?rfc=2960">(RFC2960)</url> through the user-level - <url href="http://tools.ietf.org/html/draft-ietf-tsvwg-sctpsocket-13">Sockets API Extensions.</url> - During development this implementation was tested on - Linux Fedora Core 5.0 (kernel 2.6.15-2054 or later is needed), - and on Solaris 10, 11. During OTP adaptation it was tested on - SUSE Linux Enterprise Server 10 (x86_64) kernel 2.6.16.27-0.6-smp, - with lksctp-tools-1.0.6, briefly on Solaris 10, and later on - SUSE Linux Enterprise Server 10 Service Pack 1 (x86_64) - kernel 2.6.16.54-0.2.3-smp with lksctp-tools-1.0.7, - and later also on FreeBSD 8.2. - </p> - <p> - This module was written for one-to-many style sockets + <url href="http://www.rfc-archive.org/getrfc.php?rfc=2960">(RFC 2960)</url> + through the user-level + <url href="http://tools.ietf.org/html/draft-ietf-tsvwg-sctpsocket-13">Sockets API Extensions</url>.</p> + <p>During development, this implementation was tested on:</p> + <list type="bulleted"> + <item>Linux Fedora Core 5.0 (kernel 2.6.15-2054 or later is needed)</item> + <item>Solaris 10, 11</item> + </list> + <p>During OTP adaptation it was tested on:</p> + <list type="bulleted"> + <item>SUSE Linux Enterprise Server 10 (x86_64) kernel 2.6.16.27-0.6-smp, + with lksctp-tools-1.0.6</item> + <item>Briefly on Solaris 10</item> + <item>SUSE Linux Enterprise Server 10 Service Pack 1 (x86_64) + kernel 2.6.16.54-0.2.3-smp with lksctp-tools-1.0.7</item> + <item>FreeBSD 8.2</item> + </list> + <p>This module was written for one-to-many style sockets (type <c>seqpacket</c>). With the addition of - <seealso marker="#peeloff/2">peeloff/2</seealso>, one-to-one style - sockets (type <c>stream</c>) were introduced. - </p> - <p>Record definitions for the <c>gen_sctp</c> module can be found using:</p> -<pre> -include_lib("kernel/include/inet_sctp.hrl"). </pre> + <seealso marker="#peeloff/2"><c>peeloff/2</c></seealso>, + one-to-one style sockets (type <c>stream</c>) were introduced.</p> + <p>Record definitions for this module can be found using:</p> + <pre> +-include_lib("kernel/include/inet_sctp.hrl").</pre> <p>These record definitions use the "new" spelling 'adaptation', not the deprecated 'adaption', regardless of which spelling the underlying C API uses.</p> </description> - <section> - <marker id="contents"></marker> - <title>CONTENTS</title> - <list type="bulleted"> - <item><seealso marker="#types">DATA TYPES</seealso></item> - <item><seealso marker="#exports">EXPORTS</seealso></item> - <item><seealso marker="#options">SCTP SOCKET OPTIONS</seealso></item> - <item><seealso marker="#examples">SCTP EXAMPLES</seealso></item> - <item><seealso marker="#seealso">SEE ALSO</seealso></item> - </list> - <marker id="types"></marker> - </section> - <datatypes> <datatype> <name>assoc_id()</name> <desc> <p><marker id="type-assoc_id"/> - An opaque term returned in for example #sctp_paddr_change{} - that identifies an association for an SCTP socket. The term - is opaque except for the special value <c>0</c> that has a - meaning such as "the whole endpoint" or "all future associations". - </p> + An opaque term returned in, for example, <c>#sctp_paddr_change{}</c>, + which identifies an association for an SCTP socket. The term + is opaque except for the special value <c>0</c>, which has a + meaning such as "the whole endpoint" or "all future associations".</p> </desc> </datatype> <datatype> <name name="option"/> <desc> - <p>One of the - <seealso marker="#options">SCTP Socket Options.</seealso></p> + <p>One of the + <seealso marker="#options">SCTP Socket Options</seealso>.</p> </desc> </datatype> <datatype> @@ -101,8 +93,8 @@ <datatype> <name>sctp_socket()</name> <desc> - <p><marker id="type-sctp_socket"/> - Socket identifier returned from <c>open/*</c>.</p> + <p><marker id="type-sctp_socket"/>Socket identifier returned from + <seealso marker="#open/0"><c>open/*</c></seealso>.</p> <marker id="exports"></marker> </desc> </datatype> @@ -111,405 +103,438 @@ <funcs> <func> <name name="abort" arity="2"/> - <fsummary>Abnormally terminate the association given by Assoc, without flushing of unsent data</fsummary> + <fsummary>Abnormally terminate the association specified by + <c>Assoc</c>, without flushing of unsent data.</fsummary> <desc> - <p>Abnormally terminates the association given by <c><anno>Assoc</anno></c>, without + <p>Abnormally terminates the association specified by + <c><anno>Assoc</anno></c>, without flushing of unsent data. The socket itself remains open. Other - associations opened on this socket are still valid, and it can be - used in new associations.</p> + associations opened on this socket are still valid, and the socket + can be used in new associations.</p> </desc> </func> + <func> <name name="close" arity="1"/> - <fsummary>Completely close the socket and all associations on it</fsummary> + <fsummary>Close the socket and all associations on it.</fsummary> <desc> - <p>Completely closes the socket and all associations on it. The unsent - data is flushed as in <c>eof/2</c>. The <c>close/1</c> call + <p>Closes the socket and all associations on it. The unsent + data is flushed as in <seealso marker="#eof/2"><c>eof/2</c></seealso>. + The <c>close/1</c> call is blocking or otherwise depending of the value of - the <seealso marker="inet#option-linger">linger</seealso> socket - <seealso marker="#options">option</seealso>. - If <c>close</c> does not linger or linger timeout expires, + the <seealso marker="inet#option-linger"><c>linger</c></seealso> + socket <seealso marker="#options">option</seealso>. + If <c>close</c> does not linger or linger time-out expires, the call returns and the data is flushed in the background.</p> </desc> </func> + <func> <name name="connect" arity="4"/> <fsummary>Same as <c>connect(Socket, Addr, Port, Opts, infinity)</c>.</fsummary> <desc> - <p>Same as <c>connect(<anno>Socket</anno>, <anno>Addr</anno>, <anno>Port</anno>, <anno>Opts</anno>, infinity)</c>.</p> + <p>Same as <c>connect(<anno>Socket</anno>, <anno>Addr</anno>, + <anno>Port</anno>, <anno>Opts</anno>, infinity)</c>.</p> </desc> </func> + <func> <name name="connect" arity="5"/> - <fsummary>Establish a new association for the socket <c>Socket</c>, with a peer (SCTP server socket)</fsummary> + <fsummary>Establish a new association for socket <c>Socket</c>, with a + peer (SCTP server socket).</fsummary> <desc> - <p>Establishes a new association for the socket <c><anno>Socket</anno></c>, - with the peer (SCTP server socket) given by - <c><anno>Addr</anno></c> and <c><anno>Port</anno></c>. The <c><anno>Timeout</anno></c>, - is expressed in milliseconds. A socket can be associated with multiple peers.</p> - - <p><em>WARNING:</em>Using a value of <c><anno>Timeout</anno></c> less than - the maximum time taken by the OS to establish an association (around 4.5 minutes - if the default values from RFC 4960 are used) can result in - inconsistent or incorrect return values. This is especially - relevant for associations sharing the same <c><anno>Socket</anno></c> - (i.e. source address and port) since the controlling process - blocks until <c>connect/*</c> returns. - <seealso marker="#connect_init/4">connect_init/*</seealso> - provides an alternative not subject to this limitation.</p> - + <p>Establishes a new association for socket <c><anno>Socket</anno></c>, + with the peer (SCTP server socket) specified by + <c><anno>Addr</anno></c> and <c><anno>Port</anno></c>. + <c><anno>Timeout</anno></c>, is expressed in milliseconds. + A socket can be associated with multiple peers.</p> + <warning><p>Using a value of <c><anno>Timeout</anno></c> less than + the maximum time taken by the OS to establish an association (around + 4.5 minutes if the default values from + <url href="https://tools.ietf.org/html/rfc4960">RFC 4960</url> + are used), can result + in inconsistent or incorrect return values. This is especially + relevant for associations sharing the same <c><anno>Socket</anno></c> + (that is, source address and port), as the controlling process + blocks until <c>connect/*</c> returns. + <seealso marker="#connect_init/4"><c>connect_init/*</c></seealso> + provides an alternative without this limitation.</p> + </warning> <p><marker id="record-sctp_assoc_change"></marker> The result of <c>connect/*</c> is an <c>#sctp_assoc_change{}</c> - event which contains, in particular, the new - <seealso marker="#type-assoc_id">Association ID</seealso>.</p> -<pre> #sctp_assoc_change{ - state = atom(), - error = atom(), - outbound_streams = integer(), - inbound_streams = integer(), - assoc_id = assoc_id() - } </pre> + event that contains, in particular, the new + <seealso marker="#type-assoc_id">Association ID</seealso>:</p> + <pre> +#sctp_assoc_change{ + state = atom(), + error = atom(), + outbound_streams = integer(), + inbound_streams = integer(), + assoc_id = assoc_id() +}</pre> <p>The number of outbound and inbound streams can be set by - giving an <c>sctp_initmsg</c> option to <c>connect</c> - as in:</p> -<pre> connect(Socket, Ip, Port>, - [{sctp_initmsg,#sctp_initmsg{num_ostreams=OutStreams, - max_instreams=MaxInStreams}}]) </pre> + giving an <c>sctp_initmsg</c> option to <c>connect</c> as in:</p> + <pre> +connect(Socket, Ip, Port>, + [{sctp_initmsg,#sctp_initmsg{num_ostreams=OutStreams, + max_instreams=MaxInStreams}}])</pre> <p>All options <c><anno>Opt</anno></c> are set on the socket before the - association is attempted. If an option record has got undefined + association is attempted. If an option record has undefined field values, the options record is first read from the socket - for those values. In effect, <c><anno>Opt</anno></c> option records only - define field values to change before connecting.</p> + for those values. In effect, <c><anno>Opt</anno></c> option records + only define field values to change before connecting.</p> <p>The returned <c>outbound_streams</c> and <c>inbound_streams</c> - are the actual stream numbers on the socket, which may be different - from the requested values (<c>OutStreams</c> and <c>MaxInStreams</c> + are the stream numbers on the socket. These can be different + from the requested values (<c>OutStreams</c> and <c>MaxInStreams</c>, respectively) if the peer requires lower values.</p> - <p>The following values of <c>state</c> are possible:</p> - <list type="bulleted"> - <item> - <p><c>comm_up</c>: association successfully established. This - indicates a successful completion of <c>connect</c>.</p> - </item> - <item> - <p><c>cant_assoc</c>: association cannot be established - (<c>connect/*</c> failure).</p> - </item> - </list> - <p>All other states do not normally occur in the output from - <c>connect/*</c>. Rather, they may occur in + <p><c>state</c> can have the following values:</p> + <taglist> + <tag><c>comm_up</c></tag> + <item><p>Association is successfully established. This + indicates a successful completion of <c>connect</c>.</p></item> + <tag><c>cant_assoc</c></tag> + <item><p>The association cannot be established + (<c>connect/*</c> failure).</p></item> + </taglist> + <p>Other states do not normally occur in the output from + <c>connect/*</c>. Rather, they can occur in <c>#sctp_assoc_change{}</c> events received instead of data in - <seealso marker="#recv/1">recv/*</seealso> calls. - All of them indicate losing the association due to various - error conditions, and are listed here for the sake of completeness. - The <c>error</c> field may provide more detailed diagnostics.</p> - <list type="bulleted"> - <item> - <p><c>comm_lost</c>;</p> - </item> - <item> - <p><c>restart</c>;</p> - </item> - <item> - <p><c>shutdown_comp</c>.</p> - </item> - </list> + <seealso marker="#recv/1"><c>recv/*</c></seealso> calls. + All of them indicate losing the association because of various error + conditions, and are listed here for the sake of completeness:</p> + <taglist> + <tag><c>comm_lost</c></tag> + <item></item> + <tag><c>restart</c></tag> + <item></item> + <tag><c>shutdown_comp</c></tag> + <item></item> + </taglist> + <p>Field <c>error</c> can provide more detailed diagnostics.</p> </desc> </func> + <func> <name name="connect_init" arity="4"/> - <fsummary>Same as <c>connect_init(Socket, Addr, Port, Opts, infinity)</c>.</fsummary> + <fsummary>Same as <c>connect_init(Socket, Addr, Port, Opts, infinity)</c>..</fsummary> <desc> - <p>Same as <c>connect_init(<anno>Socket</anno>, <anno>Addr</anno>, <anno>Port</anno>, <anno>Opts</anno>, infinity)</c>.</p> + <p>Same as <c>connect_init(<anno>Socket</anno>, <anno>Addr</anno>, + <anno>Port</anno>, <anno>Opts</anno>, infinity)</c>.</p> </desc> </func> + <func> <name name="connect_init" arity="5"/> - <fsummary>Initiate a new association for the socket <c>Socket</c>, with a peer (SCTP server socket)</fsummary> + <fsummary>Initiate a new association for socket <c>Socket</c>, with a + peer (SCTP server socket).</fsummary> <desc> - <p>Initiates a new association for the socket <c><anno>Socket</anno></c>, - with the peer (SCTP server socket) given by + <p>Initiates a new association for socket <c><anno>Socket</anno></c>, + with the peer (SCTP server socket) specified by <c><anno>Addr</anno></c> and <c><anno>Port</anno></c>.</p> - <p>The fundamental difference between this API - and <c>connect/*</c> is that the return value is that of the - underlying OS connect(2) system call. If <c>ok</c> is returned - then the result of the association establishement is received - by the calling process as - an <seealso marker="#record-sctp_assoc_change"> - #sctp_assoc_change{}</seealso> - event. The calling process must be prepared to receive this, or - poll for it using <c>recv/*</c> depending on the value of the - active option.</p> - <p>The parameters are as described - in <seealso marker="#connect/5">connect/*</seealso>, with the - exception of the <c><anno>Timeout</anno></c> value.</p> - <p>The timer associated with <c><anno>Timeout</anno></c> only supervises - IP resolution of <c><anno>Addr</anno></c></p> + <p>The fundamental difference between this API + and <c>connect/*</c> is that the return value is that of the + underlying OS <c>connect(2)</c> system call. If <c>ok</c> is returned, + the result of the association establishment is received + by the calling process as an + <seealso marker="#record-sctp_assoc_change"><c>#sctp_assoc_change{}</c></seealso> + event. The calling process must be prepared to receive this, or + poll for it using + <seealso marker="#recv/1"><c>recv/*</c></seealso>, + depending on the value of the active option.</p> + <p>The parameters are as described in + <seealso marker="#connect/5"><c>connect/*</c></seealso>, + except the <c><anno>Timeout</anno></c> value.</p> + <p>The timer associated with <c><anno>Timeout</anno></c> only supervises + IP resolution of <c><anno>Addr</anno></c>.</p> </desc> </func> + <func> <name name="controlling_process" arity="2"/> - <fsummary>Assign a new controlling process pid to the socket</fsummary> + <fsummary>Assign a new controlling process pid to the socket.</fsummary> <desc> - <p>Assigns a new controlling process <c><anno>Pid</anno></c> to <c><anno>Socket</anno></c>. Same implementation - as <c>gen_udp:controlling_process/2</c>.</p> + <p>Assigns a new controlling process <c><anno>Pid</anno></c> to + <c><anno>Socket</anno></c>. Same implementation as + <seealso marker="gen_udp:controlling_process/2"><c>gen_udp:controlling_process/2</c></seealso>. + </p> </desc> </func> + <func> <name name="eof" arity="2"/> - <fsummary>Gracefully terminate the association given by Assoc, with flushing of all unsent data</fsummary> + <fsummary>Gracefully terminate the association specified by <c>Assoc</c>, + with flushing of all unsent data.</fsummary> <desc> - <p>Gracefully terminates the association given by <c><anno>Assoc</anno></c>, with + <p>Gracefully terminates the association specified by + <c><anno>Assoc</anno></c>, with flushing of all unsent data. The socket itself remains open. Other - associations opened on this socket are still valid, and it can be - used in new associations.</p> + associations opened on this socket are still valid. The socket can + be used in new associations.</p> + </desc> + </func> + + <func> + <name name="error_string" arity="1"/> + <fsummary>Translate an SCTP error number into a string.</fsummary> + <desc> + <p>Translates an SCTP error number from, for example, + <c>#sctp_remote_error{}</c> or <c>#sctp_send_failed{}</c> into + an explanatory string, or one of the atoms <c>ok</c> for no + error or <c>undefined</c> for an unrecognized error.</p> </desc> </func> + <func> <name name="listen" arity="2" clause_i="1"/> <name name="listen" arity="2" clause_i="2"/> <fsummary>Set up a socket to listen.</fsummary> <desc> <p>Sets up a socket to listen on the IP address and port number - it is bound to.</p> - <p>For type <c>seqpacket</c> sockets (the default) - <c><anno>IsServer</anno></c> must be <c>true</c> or <c>false</c>. - In contrast to TCP, in SCTP there is no listening queue length. - If <c><anno>IsServer</anno></c> is <c>true</c> the socket accepts new associations, i.e. - it will become an SCTP server socket.</p> - <p>For type <c>stream</c> sockets <anno>Backlog</anno> defines - the backlog queue length just like in TCP.</p> + it is bound to.</p> + <p>For type <c>seqpacket</c>, sockets (the default) + <c><anno>IsServer</anno></c> must be <c>true</c> or <c>false</c>. + In contrast to TCP, there is no listening queue length in SCTP. + If <c><anno>IsServer</anno></c> is <c>true</c>, the socket accepts + new associations, that is, it becomes an SCTP server socket.</p> + <p>For type <c>stream</c>, sockets <anno>Backlog</anno> define + the backlog queue length just like in TCP.</p> </desc> </func> + <func> <name name="open" arity="0"/> <name name="open" arity="1" clause_i="1"/> <name name="open" arity="1" clause_i="2"/> <name name="open" arity="2"/> - <fsummary>Create an SCTP socket and bind it to local addresses</fsummary> + <fsummary>Create an SCTP socket and binds it to local addresses.</fsummary> <desc> - <p>Creates an SCTP socket and binds it to the local addresses - specified by all <c>{ip,<anno>IP</anno>}</c> (or synonymously <c>{ifaddr,<anno>IP</anno>}</c>) - options (this feature is called SCTP multi-homing). - The default <c><anno>IP</anno></c> and <c><anno>Port</anno></c> are <c>any</c> + <p>Creates an SCTP socket and binds it to the local addresses + specified by all <c>{ip,<anno>IP</anno>}</c> (or synonymously + <c>{ifaddr,<anno>IP</anno>}</c>) + options (this feature is called SCTP multi-homing). The default + <c><anno>IP</anno></c> and <c><anno>Port</anno></c> are <c>any</c> and <c>0</c>, meaning bind to all local addresses on any - one free port.</p> - - <p>Other options are:</p> + free port.</p> + <p>Other options:</p> <taglist> <tag><c>inet6</c></tag> <item> - <p>Set up the socket for IPv6.</p> + <p>Sets up the socket for IPv6.</p> </item> <tag><c>inet</c></tag> <item> - <p>Set up the socket for IPv4. This is the default.</p> + <p>Sets up the socket for IPv4. This is the default.</p> </item> </taglist> - <p>A default set of socket <seealso marker="#options">options</seealso> - is used. In particular, the socket is opened in + is used. In particular, the socket is opened in <seealso marker="#option-binary">binary</seealso> and <seealso marker="#option-active">passive</seealso> mode, - with <anno>SockType</anno> <c>seqpacket</c>, - and with reasonably large + with <anno>SockType</anno> <c>seqpacket</c>, and with reasonably large <seealso marker="inet#option-sndbuf">kernel</seealso> and driver - <seealso marker="inet#option-buffer">buffers.</seealso></p> + <seealso marker="inet#option-buffer">buffers</seealso>.</p> </desc> </func> + <func> <name name="peeloff" arity="2"/> - <fsummary> - Peel off a type <c>stream</c> socket from a type <c>seqpacket</c> one - </fsummary> + <fsummary>Peel off a type <c>stream</c> socket from a type + <c>seqpacket</c> one.</fsummary> <desc> - <p> - Branch off an existing association <anno>Assoc</anno> - in a socket <anno>Socket</anno> of type <c>seqpacket</c> - (one-to-many style) into - a new socket <anno>NewSocket</anno> of type <c>stream</c> - (one-to-one style). - </p> - <p> - The existing association argument <anno>Assoc</anno> - can be either a - <seealso marker="#record-sctp_assoc_change"> - #sctp_assoc_change{} - </seealso> - record as returned from e.g - <seealso marker="#recv-2">recv/*</seealso>, - <seealso marker="#connect-5">connect/*</seealso> or - from a listening socket in active mode. Or it can be just - the field <c>assoc_id</c> integer from such a record. - </p> + <p>Branches off an existing association <c><anno>Assoc</anno></c> + in a socket <c><anno>Socket</anno></c> of type <c>seqpacket</c> + (one-to-many style) into + a new socket <c><anno>NewSocket</anno></c> of type <c>stream</c> + (one-to-one style).</p> + <p>The existing association argument <c><anno>Assoc</anno></c> + can be either a + <seealso marker="#record-sctp_assoc_change"><c>#sctp_assoc_change{}</c></seealso> + record as returned from, for example, + <seealso marker="#recv-2"><c>recv/*</c></seealso>, + <seealso marker="#connect-5"><c>connect/*</c></seealso>, or + from a listening socket in active mode. It can also be just + the field <c>assoc_id</c> integer from such a record.</p> </desc> </func> + <func> <name name="recv" arity="1"/> <name name="recv" arity="2"/> - <fsummary>Receive a message from a socket</fsummary> + <fsummary>Receive a message from a socket.</fsummary> <desc> - <p>Receives the <c><anno>Data</anno></c> message from any association of the socket. - If the receive times out <c>{error,timeout</c> is returned. - The default timeout is <c>infinity</c>. - <c><anno>FromIP</anno></c> and <c><anno>FromPort</anno></c> indicate the sender's address.</p> - <p><c><anno>AncData</anno></c> is a list of Ancillary Data items which - may be received along with the main <c><anno>Data</anno></c>. + <p>Receives the <c><anno>Data</anno></c> message from any association + of the socket. + If the receive times out, <c>{error,timeout}</c> is returned. + The default time-out is <c>infinity</c>. <c><anno>FromIP</anno></c> + and <c><anno>FromPort</anno></c> indicate the address of the + sender.</p> + <p><c><anno>AncData</anno></c> is a list of ancillary data items that + can be received along with the main <c><anno>Data</anno></c>. This list can be empty, or contain a single - <seealso marker="#record-sctp_sndrcvinfo">#sctp_sndrcvinfo{}</seealso> - record, if receiving of such ancillary data is enabled - (see option - <seealso marker="#option-sctp_events">sctp_events</seealso>). - It is enabled by default, since such ancillary data - provide an easy way of determining the association and stream - over which the message has been received. - (An alternative way would be to get the Association ID from the - <c><anno>FromIP</anno></c> and <c><anno>FromPort</anno></c> using the - <seealso marker="#option-sctp_get_peer_addr_info">sctp_get_peer_addr_info</seealso> socket option, - but this would still not produce the Stream number).</p> - <p>The actual <c><anno>Data</anno></c> received may be a <c>binary()</c>, - or <c>list()</c> of bytes (integers in the range 0 through 255) - depending on the socket mode, or an SCTP Event. - <marker id="sctp_events"></marker> - - The following SCTP Events are possible:</p> + <seealso marker="#record-sctp_sndrcvinfo"><c>#sctp_sndrcvinfo{}</c></seealso> + record if receiving of such ancillary data is enabled (see option + <seealso marker="#option-sctp_events"><c>sctp_events</c></seealso>). + It is enabled by default, as such ancillary data + provides an easy way of determining the association and stream + over which the message is received. + (An alternative way is to get the association ID from + <c><anno>FromIP</anno></c> and <c><anno>FromPort</anno></c> using + socket option + <seealso marker="#option-sctp_get_peer_addr_info"><c>sctp_get_peer_addr_info</c></seealso>, + but this does still not produce the stream number).</p> + <p>The <c><anno>Data</anno></c> received can be a <c>binary()</c> + or a <c>list()</c> of bytes (integers in the range 0 through 255) + depending on the socket mode, or an SCTP event.</p> + <marker id="sctp_events"></marker> + <p>Possible SCTP events:</p> <list type="bulleted"> <item> - <p><seealso marker="#record-sctp_sndrcvinfo">#sctp_sndrcvinfo{}</seealso></p> + <seealso marker="#record-sctp_sndrcvinfo"><c>#sctp_sndrcvinfo{}</c></seealso> </item> <item> - <p><seealso marker="#record-sctp_assoc_change">#sctp_assoc_change{}</seealso>;</p> + <seealso marker="#record-sctp_assoc_change"><c>#sctp_assoc_change{}</c></seealso> </item> <item> -<pre> #sctp_paddr_change{ - addr = {ip_address(),port()}, - state = atom(), - error = integer(), - assoc_id = assoc_id() - } </pre> - <p>Indicates change of the status of the peer's IP address given by - <c>addr</c> within the association <c>assoc_id</c>. - Possible values of <c>state</c> (mostly self-explanatory) include:</p> - <list type="bulleted"> - <item> - <p><c>addr_unreachable</c>;</p> - </item> - <item> - <p><c>addr_available</c>;</p> - </item> - <item> - <p><c>addr_removed</c>;</p> - </item> - <item> - <p><c>addr_added</c>;</p> + <pre> +#sctp_paddr_change{ + addr = {ip_address(),port()}, + state = atom(), + error = integer(), + assoc_id = assoc_id() +}</pre> + <p>Indicates change of the status of the IP address of the peer + specified by + <c>addr</c> within association <c>assoc_id</c>. Possible + values of <c>state</c> (mostly self-explanatory) include:</p> + <taglist> + <tag><c>addr_unreachable</c></tag> + <item></item> + <tag><c>addr_available</c></tag> + <item></item> + <tag><c>addr_removed</c></tag> + <item></item> + <tag><c>addr_added</c></tag> + <item></item> + <tag><c>addr_made_prim</c></tag> + <item></item> + <tag><c>addr_confirmed</c></tag> + <item></item> + </taglist> + <p>In case of an error (for example, <c>addr_unreachable</c>), + field <c>error</c> provides more diagnostics. In such cases, + event <c>#sctp_paddr_change{}</c> is automatically + converted into an <c>error</c> term returned by + <seealso marker="#recv/1"><c>recv</c></seealso>. + The <c>error</c> field value can be converted into a string using + <seealso marker="#error_string/1"><c>error_string/1</c></seealso>. + </p> + </item> + <item> + <pre> +#sctp_send_failed{ + flags = true | false, + error = integer(), + info = #sctp_sndrcvinfo{}, + assoc_id = assoc_id() + data = binary() +}</pre> + <p>The sender can receive this event if a send operation fails.</p> + <taglist> + <tag><c>flags</c></tag> + <item><p>A Boolean specifying if the data has been transmitted + over the wire.</p></item> + <tag><c>error</c></tag> + <item><p>Provides extended diagnostics, use + <seealso marker="#error_string/1"><c>error_string/1</c>.</seealso></p> </item> - <item> - <p><c>addr_made_prim</c>.</p> + <tag><c>info</c></tag> + <item><p>The original + <seealso marker="#record-sctp_sndrcvinfo"><c>#sctp_sndrcvinfo{}</c></seealso> + record used in the failed + <seealso marker="#send/3"><c>send/*</c>.</seealso></p> </item> - <item> - <p><c>addr_confirmed</c>.</p> + <tag><c>data</c></tag> + <item><p>The whole original data chunk attempted to be sent.</p> </item> - </list> - <p>In case of an error (e.g. <c>addr_unreachable</c>), the - <c>error</c> field provides additional diagnostics. In such cases, - the <c>#sctp_paddr_change{}</c> Event is automatically - converted into an <c>error</c> term returned by - <c>gen_sctp:recv</c>. The <c>error</c> field value can be - converted into a string using <c>error_string/1</c>.</p> - </item> - <item> -<pre> #sctp_send_failed{ - flags = true | false, - error = integer(), - info = #sctp_sndrcvinfo{}, - assoc_id = assoc_id() - data = binary() - } </pre> - <p>The sender may receive this event if a send operation fails. - The <c>flags</c> is a Boolean specifying whether the data have - actually been transmitted over the wire; <c>error</c> provides - extended diagnostics, use <c>error_string/1</c>; - <c>info</c> is the original - <seealso marker="#record-sctp_sndrcvinfo">#sctp_sndrcvinfo{}</seealso> record used in the failed - <seealso marker="#send/3">send/*,</seealso> and <c>data</c> - is the whole original data chunk attempted to be sent.</p> + </taglist> <p>In the current implementation of the Erlang/SCTP binding, - this Event is internally converted into an <c>error</c> term - returned by <c>recv/*</c>.</p> + this event is internally converted into an <c>error</c> term + returned by + <seealso marker="#recv/1"><c>recv/*</c></seealso>.</p> </item> <item> -<pre> #sctp_adaptation_event{ - adaptation_ind = integer(), - assoc_id = assoc_id() - } </pre> - <p>Delivered when a peer sends an Adaptation Layer Indication - parameter (configured through the option - <seealso marker="#option-sctp_adaptation_layer">sctp_adaptation_layer</seealso>). - Note that with the current implementation of + <pre> +#sctp_adaptation_event{ + adaptation_ind = integer(), + assoc_id = assoc_id() +}</pre> + <p>Delivered when a peer sends an adaptation layer indication + parameter (configured through option + <seealso marker="#option-sctp_adaptation_layer"><c>sctp_adaptation_layer</c></seealso>). + Notice that with the current implementation of the Erlang/SCTP binding, this event is disabled by default.</p> </item> <item> -<pre> #sctp_pdapi_event{ - indication = sctp_partial_delivery_aborted, - assoc_id = assoc_id() - } </pre> + <pre> +#sctp_pdapi_event{ + indication = sctp_partial_delivery_aborted, + assoc_id = assoc_id() +}</pre> <p>A partial delivery failure. In the current implementation of - the Erlang/SCTP binding, this Event is internally converted - into an <c>error</c> term returned by <c>recv/*</c>.</p> + the Erlang/SCTP binding, this event is internally converted + into an <c>error</c> term returned by + <seealso marker="#recv/1"><c>recv/*</c></seealso>.</p> </item> </list> </desc> </func> + <func> <name name="send" arity="3"/> - <fsummary>Send a message using an <c>#sctp_sndrcvinfo{}</c>record</fsummary> + <fsummary>Send a message using an <c>#sctp_sndrcvinfo{}</c>record.</fsummary> <desc> - <p>Sends the <c><anno>Data</anno></c> message with all sending parameters from a - <seealso marker="#record-sctp_sndrcvinfo">#sctp_sndrcvinfo{}</seealso> record. - This way, the user can specify the PPID (passed to the remote end) - and Context (passed to the local SCTP layer) which can be used - for example for error identification. + <p>Sends the <c><anno>Data</anno></c> message with all sending + parameters from a + <seealso marker="#record-sctp_sndrcvinfo"><c>#sctp_sndrcvinfo{}</c></seealso> + record. This way, the user can specify the PPID (passed to the remote + end) and context (passed to the local SCTP layer), which can be used, + for example, for error identification. However, such a fine level of user control is rarely required. - The send/4 function is sufficient for most applications.</p> + The function <c>send/4</c> is sufficient for most applications.</p> </desc> </func> + <func> <name name="send" arity="4"/> - <fsummary>Send a message over an existing association and given stream</fsummary> + <fsummary>Send a message over an existing association and specified + stream.</fsummary> <desc> - <p>Sends <c><anno>Data</anno></c> message over an existing association and given - stream.</p> - </desc> - </func> - <func> - <name name="error_string" arity="1"/> - <fsummary>Translate an SCTP error number into a string</fsummary> - <desc> - <p>Translates an SCTP error number from for example - <c>#sctp_remote_error{}</c> or <c>#sctp_send_failed{}</c> into - an explanatory string, or one of the atoms <c>ok</c> for no - error and <c>undefined</c> for an unrecognized error.</p> + <p>Sends a <c><anno>Data</anno></c> message over an existing association + and specified stream.</p> </desc> </func> </funcs> <section> <marker id="options"></marker> - <title>SCTP SOCKET OPTIONS</title> + <title>SCTP Socket Options</title> <p>The set of admissible SCTP socket options is by construction - orthogonal to the sets of TCP, UDP and generic INET options: - only those options which are explicitly listed below are allowed + orthogonal to the sets of TCP, UDP, and generic <c>inet</c> options. + Only options listed here are allowed for SCTP sockets. Options can be set on the socket using - <seealso marker="#open/1"><c>gen_sctp:open/1,2</c></seealso> - or <seealso marker="inet#setopts/2"><c>inet:setopts/2</c></seealso>, - retrieved using <seealso marker="inet#getopts/2"><c>inet:getopts/2</c></seealso>, - and when calling <seealso marker="#connect/4"><c>gen_sctp:connect/4,5</c></seealso> - options can be changed.</p> + <seealso marker="#open/1"><c>open/1,2</c></seealso> or + <seealso marker="inet#setopts/2"><c>inet:setopts/2</c></seealso>, + retrieved using + <seealso marker="inet#getopts/2"><c>inet:getopts/2</c></seealso>. + Options can be changed when calling + <seealso marker="#connect/4"><c>connect/4,5</c></seealso>.</p> <marker id="option-binary"></marker> <marker id="option-list"></marker> <taglist> <tag><c>{mode, list|binary}</c> or just <c>list</c> or <c>binary</c></tag> <item> - <p>Determines the type of data returned from <c>gen_sctp:recv/1,2</c>.</p> + <p>Determines the type of data returned from + <seealso marker="#recv/1"><c>recv/1,2</c></seealso>.</p> <marker id="option-active"></marker> </item> <tag><c>{active, true|false|once|N}</c></tag> @@ -517,176 +542,177 @@ <list type="bulleted"> <item> <p>If <c>false</c> (passive mode, the default), - the caller needs to do an explicit <c>gen_sctp:recv</c> call - in order to retrieve the available data from the socket.</p> + the caller must do an explicit + <seealso marker="#recv/1"><c>recv</c></seealso> call + to retrieve the available data from the socket.</p> </item> <item> <p>If <c>true</c> (full active mode), the pending data or events are sent to the owning process.</p> - <p><em>NB:</em> This can cause the message queue to overflow, + <p>Notice that this can cause the message queue to overflow, as there is no way to throttle the sender in this case - (no flow control!).</p> + (no flow control).</p> </item> <item> <p>If <c>once</c>, only one message is automatically placed in the message queue, and after that the mode is automatically - reset to passive. This provides flow control as well as + reset to passive. This provides flow control and the possibility for the receiver to listen for its incoming SCTP data interleaved with other inter-process messages.</p> </item> <item> <p>If <c>active</c> is specified as an integer <c>N</c> in the - range -32768 to 32767 (inclusive), then that number is added to - the socket's count of the number of data messages to be + range -32768 to 32767 (inclusive), that number is added to + the socket's counting of data messages to be delivered to the controlling process. If the result of the - addition would be negative, the count is set to 0. Once the - count reaches 0, either through the delivery of messages or by - being explicitly set with <seealso - marker="inet#setopts/2">inet:setopts/2</seealso>, the socket's - mode is automatically reset to passive (<c>{active, - false}</c>) mode. When a socket in this active mode transitions to + addition is negative, the count is set to <c>0</c>. Once the + count reaches <c>0</c>, either through the delivery of messages + or by being explicitly set with + <seealso marker="inet#setopts/2"><c>inet:setopts/2</c></seealso>, + the socket mode is automatically reset to passive (<c>{active, + false}</c>). When a socket in this active mode transitions to passive mode, the message <c>{sctp_passive, Socket}</c> is sent to the controlling process to notify it that if it wants to receive more data messages from the socket, it must call - <seealso marker="inet#setopts/2">inet:setopts/2</seealso> to set - the socket back into an active mode.</p> + <seealso marker="inet#setopts/2"><c>inet:setopts/2</c></seealso> + to set the socket back into an active mode.</p> </item> </list> </item> - <tag><c>{tos, integer()}</c></tag> + <tag><c>{tos, integer()}</c></tag> <item> - <p>Sets the Type-Of-Service field on the IP datagrams being sent, - to the given value, which effectively determines a prioritization + <p>Sets the Type-Of-Service field on the IP datagrams that are sent, + to the specified value. This effectively determines a prioritization policy for the outbound packets. The acceptable values - are system-dependent. TODO: we do not provide - symbolic names for these values yet.</p> + are system-dependent.</p> </item> <tag><c>{priority, integer()}</c></tag> <item> <p>A protocol-independent equivalent of <c>tos</c> above. Setting - priority implies setting tos as well.</p> + priority implies setting <c>tos</c> as well.</p> </item> <tag><c>{dontroute, true|false}</c></tag> <item> - <p>By default <c>false</c>. If <c>true</c>, the kernel does not - send packets via any gateway, only sends them to directly + <p>Defaults to <c>false</c>. If <c>true</c>, the kernel does not + send packets through any gateway, only sends them to directly connected hosts.</p> </item> <tag><c>{reuseaddr, true|false}</c></tag> <item> - <p>By default <c>false</c>. If true, the local binding address - <c>{IP,Port}</c> of the socket can be re-used immediately: - no waiting in the CLOSE_WAIT state is performed (may be + <p>Defaults to <c>false</c>. If true, the local binding address + <c>{IP,Port}</c> of the socket can be reused immediately. + No waiting in state <c>CLOSE_WAIT</c> is performed (can be required for high-throughput servers).</p> </item> - <tag><c>{sndbuf, integer()}</c></tag> + <tag><c>{sndbuf, integer()}</c></tag> <item> - <p>The size, in bytes, of the *kernel* send buffer for this socket. + <p>The size, in bytes, of the OS kernel send buffer for this socket. Sending errors would occur for datagrams larger than <c>val(sndbuf)</c>. Setting this option also adjusts the size of the driver buffer (see <c>buffer</c> above).</p> </item> <tag><c>{recbuf, integer()}</c></tag> <item> - <p>The size, in bytes, of the *kernel* recv buffer for this socket. + <p>The size, in bytes, of the OS kernel receive buffer for this socket. Sending errors would occur for datagrams larger than - <c>val(sndbuf)</c>. Setting this option also adjusts + <c>val(recbuf)</c>. Setting this option also adjusts the size of the driver buffer (see <c>buffer</c> above).</p> </item> - - <tag><c>{sctp_module, module()}</c></tag> - <item> <p> - Override which callback module is used. Defaults to - <c>inet_sctp</c> for IPv4 and <c>inet6_sctp</c> for IPv6. - </p> - </item> - - + <tag><c>{sctp_module, module()}</c></tag> + <item> + <p>Overrides which callback module is used. Defaults to + <c>inet_sctp</c> for IPv4 and <c>inet6_sctp</c> for IPv6.</p> + </item> <tag><c>{sctp_rtoinfo, #sctp_rtoinfo{}}</c></tag> <item> -<pre> #sctp_rtoinfo{ - assoc_id = assoc_id(), - initial = integer(), - max = integer(), - min = integer() - } </pre> - <p>Determines re-transmission time-out parameters, in milliseconds, - for the association(s) given by <c>assoc_id</c>. - If <c>assoc_id = 0</c> (default) indicates the whole endpoint. See - <url href="http://www.rfc-archive.org/getrfc.php?rfc=2960">RFC2960</url> and - <url href="http://tools.ietf.org/html/draft-ietf-tsvwg-sctpsocket-13">Sockets API Extensions for SCTP</url> for the exact semantics of the fields values.</p> + <pre> +#sctp_rtoinfo{ + assoc_id = assoc_id(), + initial = integer(), + max = integer(), + min = integer() +}</pre> + <p>Determines retransmission time-out parameters, in milliseconds, + for the association(s) specified by <c>assoc_id</c>.</p> + <p><c>assoc_id = 0</c> (default) indicates the whole endpoint. See + <url href="http://www.rfc-archive.org/getrfc.php?rfc=2960">RFC + 2960</url> and + <url href="http://tools.ietf.org/html/draft-ietf-tsvwg-sctpsocket-13">Sockets + API Extensions for SCTP</url> + for the exact semantics of the field values.</p> </item> <tag><c>{sctp_associnfo, #sctp_assocparams{}}</c></tag> <item> -<pre> #sctp_assocparams{ - assoc_id = assoc_id(), - asocmaxrxt = integer(), - number_peer_destinations = integer(), - peer_rwnd = integer(), - local_rwnd = integer(), - cookie_life = integer() - } </pre> - <p>Determines association parameters for the association(s) given by - <c>assoc_id</c>. <c>assoc_id = 0</c> (default) indicates - the whole endpoint. See - <url href="http://tools.ietf.org/html/draft-ietf-tsvwg-sctpsocket-13">Sockets API Extensions for SCTP</url> for the discussion of their semantics. Rarely used.</p> + <pre> +#sctp_assocparams{ + assoc_id = assoc_id(), + asocmaxrxt = integer(), + number_peer_destinations = integer(), + peer_rwnd = integer(), + local_rwnd = integer(), + cookie_life = integer() +}</pre> + <p>Determines association parameters for the association(s) specified by + <c>assoc_id</c>.</p> + <p><c>assoc_id = 0</c> (default) indicates the whole endpoint. See + <url href="http://tools.ietf.org/html/draft-ietf-tsvwg-sctpsocket-13">Sockets API Extensions for SCTP</url> + for the discussion of their semantics. Rarely used.</p> </item> <tag><c>{sctp_initmsg, #sctp_initmsg{}}</c></tag> <item> -<pre> #sctp_initmsg{ - num_ostreams = integer(), - max_instreams = integer(), - max_attempts = integer(), - max_init_timeo = integer() - } </pre> - <p>Determines the default parameters which this socket attempts + <pre> +#sctp_initmsg{ + num_ostreams = integer(), + max_instreams = integer(), + max_attempts = integer(), + max_init_timeo = integer() +}</pre> + <p>Determines the default parameters that this socket tries to negotiate with its peer while establishing an association with it. - Should be set after <c>open/*</c> but before the first - <c>connect/*</c>. <c>#sctp_initmsg{}</c> can also be used - as ancillary data with the first call of <c>send/*</c> to + Is to be set after + <seealso marker="#open/1"><c>open/*</c></seealso> + but before the first + <seealso marker="#connect/4"><c>connect/*</c></seealso>. + <c>#sctp_initmsg{}</c> can also be used + as ancillary data with the first call of + <seealso marker="#send/3"><c>send/*</c></seealso> to a new peer (when a new association is created).</p> - <list type="bulleted"> - <item> - <p><c>num_ostreams</c>: number of outbound streams;</p> - </item> - <item> - <p><c>max_instreams</c>: max number of in-bound streams;</p> - </item> - <item> - <p><c>max_attempts</c>: max re-transmissions while - establishing an association;</p> - </item> - <item> - <p><c>max_init_timeo</c>: time-out in milliseconds - for establishing an association.</p> - </item> - </list> + <taglist> + <tag><c>num_ostreams</c></tag> + <item>Number of outbound streams</item> + <tag><c>max_instreams</c></tag> + <item>Maximum number of inbound streams</item> + <tag><c>max_attempts</c></tag> + <item>Maximum retransmissions while establishing an association</item> + <tag><c>max_init_timeo</c></tag> + <item>Time-out, in milliseconds, for establishing an association</item> + </taglist> </item> <tag><c>{sctp_autoclose, integer() >= 0}</c></tag> <item> - <p>Determines the time (in seconds) after which an idle association is + <p>Determines the time, in seconds, after which an idle association is automatically closed. <c>0</c> means that the association is never automatically closed.</p> </item> <tag><c>{sctp_nodelay, true|false}</c></tag> <item> <p>Turns on|off the Nagle algorithm for merging small packets - into larger ones (which improves throughput at the expense - of latency).</p> + into larger ones. This improves throughput at the expense + of latency.</p> </item> <tag><c>{sctp_disable_fragments, true|false}</c></tag> <item> <p>If <c>true</c>, induces an error on an attempt to send - a message which is larger than the current PMTU size - (which would require fragmentation/re-assembling). - Note that message fragmentation does not affect + a message larger than the current PMTU size + (which would require fragmentation/reassembling). + Notice that message fragmentation does not affect the logical atomicity of its delivery; this option is provided for performance reasons only.</p> </item> <tag><c>{sctp_i_want_mapped_v4_addr, true|false}</c></tag> <item> <p>Turns on|off automatic mapping of IPv4 addresses into IPv6 ones - (if the socket address family is AF_INET6).</p> + (if the socket address family is <c>AF_INET6</c>).</p> </item> <tag><c>{sctp_maxseg, integer()}</c></tag> <item> @@ -695,176 +721,171 @@ </item> <tag><c>{sctp_primary_addr, #sctp_prim{}}</c></tag> <item> -<pre> #sctp_prim{ - assoc_id = assoc_id(), - addr = {IP, Port} - } - IP = ip_address() - Port = port_number() </pre> - <p>For the association given by <c>assoc_id</c>, - <c>{IP,Port}</c> must be one of the peer's addresses. - This option determines that the given address is - treated by the local SCTP stack as the peer's primary address.</p> + <pre> +#sctp_prim{ + assoc_id = assoc_id(), + addr = {IP, Port} +} + IP = ip_address() + Port = port_number()</pre> + <p>For the association specified by <c>assoc_id</c>, + <c>{IP,Port}</c> must be one of the peer addresses. + This option determines that the specified address is treated by + the local SCTP stack as the primary address of the peer.</p> </item> <tag><c>{sctp_set_peer_primary_addr, #sctp_setpeerprim{}}</c></tag> <item> -<pre> #sctp_setpeerprim{ - assoc_id = assoc_id(), - addr = {IP, Port} - } - IP = ip_address() - Port = port_number() </pre> - <p>When set, informs the peer that it should use <c>{IP, Port}</c> + <pre> +#sctp_setpeerprim{ + assoc_id = assoc_id(), + addr = {IP, Port} +} + IP = ip_address() + Port = port_number()</pre> + <p>When set, informs the peer to use <c>{IP, Port}</c> as the primary address of the local endpoint for the association - given by <c>assoc_id</c>.</p> + specified by <c>assoc_id</c>.</p> <marker id="option-sctp_adaptation_layer"></marker> </item> <tag><c>{sctp_adaptation_layer, #sctp_setadaptation{}}</c></tag> <item> <marker id="record-sctp_setadaptation"></marker> -<pre> #sctp_setadaptation{ - adaptation_ind = integer() - } </pre> - <p>When set, requests that the local endpoint uses the value given by - <c>adaptation_ind</c> as the Adaptation Indication parameter for - establishing new associations. See - <url href="http://www.rfc-archive.org/getrfc.php?rfc=2960">RFC2960</url> and - <url href="http://tools.ietf.org/html/draft-ietf-tsvwg-sctpsocket-13">Sockets API Extenstions for SCTP</url> for more details.</p> + <pre> +#sctp_setadaptation{ + adaptation_ind = integer() +}</pre> + <p>When set, requests that the local endpoint uses the value specified + by <c>adaptation_ind</c> as the Adaptation Indication parameter for + establishing new associations. For details, see + <url href="http://www.rfc-archive.org/getrfc.php?rfc=2960">RFC 2960</url> + and + <url href="http://tools.ietf.org/html/draft-ietf-tsvwg-sctpsocket-13">Sockets + API Extenstions for SCTP</url>.</p> </item> <tag><c>{sctp_peer_addr_params, #sctp_paddrparams{}}</c></tag> <item> -<pre> #sctp_paddrparams{ - assoc_id = assoc_id(), - address = {IP, Port}, - hbinterval = integer(), - pathmaxrxt = integer(), - pathmtu = integer(), - sackdelay = integer(), - flags = list() - } - IP = ip_address() - Port = port_number() </pre> - <p>This option determines various per-address parameters for - the association given by <c>assoc_id</c> and the peer address - <c>address</c> (the SCTP protocol supports multi-homing, - so more than 1 address can correspond to a given association).</p> - <list type="bulleted"> - <item> - <p><c>hbinterval</c>: heartbeat interval, in milliseconds;</p> - </item> - <item> - <p><c>pathmaxrxt</c>: max number of retransmissions - before this address is considered unreachable (and an - alternative address is selected);</p> - </item> - <item> - <p><c>pathmtu</c>: fixed Path MTU, if automatic discovery is - disabled (see <c>flags</c> below);</p> - </item> - <item> - <p><c>sackdelay</c>: delay in milliseconds for SAC messages - (if the delay is enabled, see <c>flags</c> below);</p> - </item> - <item> - <p><c>flags</c>: the following flags are available:</p> - <list type="bulleted"> - <item> - <p><c>hb_enable</c>: enable heartbeat; </p> - </item> - <item> - <p><c>hb_disable</c>: disable heartbeat;</p> - </item> - <item> - <p><c>hb_demand</c>: initiate heartbeat immediately;</p> - </item> - <item> - <p><c>pmtud_enable</c>: enable automatic Path MTU discovery;</p> - </item> - <item> - <p><c>pmtud_disable</c>: disable automatic Path MTU discovery;</p> - </item> - <item> - <p><c>sackdelay_enable</c>: enable SAC delay;</p> - </item> - <item> - <p><c>sackdelay_disable</c>: disable SAC delay.</p> - </item> - </list> + <pre> +#sctp_paddrparams{ + assoc_id = assoc_id(), + address = {IP, Port}, + hbinterval = integer(), + pathmaxrxt = integer(), + pathmtu = integer(), + sackdelay = integer(), + flags = list() +} +IP = ip_address() +Port = port_number()</pre> + <p>Determines various per-address parameters for + the association specified by <c>assoc_id</c> and the peer address + <c>address</c> (the SCTP protocol supports multi-homing, so + more than one address can correspond to a specified association).</p> + <taglist> + <tag><c>hbinterval</c></tag> + <item><p>Heartbeat interval, in milliseconds</p></item> + <tag><c>pathmaxrxt</c></tag> + <item><p>Maximum number of retransmissions before this address is + considered unreachable (and an alternative address is selected)</p> </item> - </list> + <tag><c>pathmtu</c></tag> + <item><p>Fixed Path MTU, if automatic discovery is disabled (see + <c>flags</c> below)</p></item> + <tag><c>sackdelay</c></tag> + <item><p>Delay, in milliseconds, for SAC messages (if the delay is + enabled, see <c>flags</c> below)</p></item> + <tag><c>flags</c></tag> + <item><p>The following flags are available:</p> + <taglist> + <tag><c>hb_enable</c></tag> + <item>Enables heartbeat</item> + <tag><c>hb_disable</c></tag> + <item>Disables heartbeat</item> + <tag><c>hb_demand</c></tag> + <item>Initiates heartbeat immediately</item> + <tag><c>pmtud_enable</c></tag> + <item>Enables automatic Path MTU discovery</item> + <tag><c>pmtud_disable</c></tag> + <item>Disables automatic Path MTU discovery</item> + <tag><c>sackdelay_enable</c></tag> + <item>Enables SAC delay</item> + <tag><c>sackdelay_disable</c></tag> + <item>Disables SAC delay</item> + </taglist></item> + </taglist> </item> <tag><c>{sctp_default_send_param, #sctp_sndrcvinfo{}}</c></tag> <item> <marker id="record-sctp_sndrcvinfo"></marker> -<pre> #sctp_sndrcvinfo{ - stream = integer(), - ssn = integer(), - flags = list(), - ppid = integer(), - context = integer(), - timetolive = integer(), - tsn = integer(), - cumtsn = integer(), - assoc_id = assoc_id() - } </pre> + <pre> +#sctp_sndrcvinfo{ + stream = integer(), + ssn = integer(), + flags = list(), + ppid = integer(), + context = integer(), + timetolive = integer(), + tsn = integer(), + cumtsn = integer(), + assoc_id = assoc_id() +}</pre> <p><c>#sctp_sndrcvinfo{}</c> is used both in this socket option, and as ancillary data while sending or receiving SCTP messages. When - set as an option, it provides a default values for subsequent - <c>gen_sctp:send</c>calls on the association given by - <c>assoc_id</c>. <c>assoc_id = 0</c> (default) indicates - the whole endpoint. The following fields typically need - to be specified by the sender:</p> - <list type="bulleted"> - <item> - <p><c>sinfo_stream</c>: stream number (0-base) within the association - to send the messages through;</p> - </item> - <item> - <p><c>sinfo_flags</c>: the following flags are recognised:</p> - <list type="bulleted"> - <item> - <p><c>unordered</c>: the message is to be sent unordered;</p> - </item> - <item> - <p><c>addr_over</c>: the address specified in - <c>gen_sctp:send</c> overwrites the primary peer address;</p> - </item> - <item> - <p><c>abort</c>: abort the current association without - flushing any unsent data;</p> - </item> - <item> - <p><c>eof</c>: gracefully shut down the current - association, with flushing of unsent data.</p> - </item> - </list> - <p>Other fields are rarely used. See - <url href="http://www.rfc-archive.org/getrfc.php?rfc=2960">RFC2960</url> and - <url href="http://tools.ietf.org/html/draft-ietf-tsvwg-sctpsocket-13">Sockets API Extensions for SCTP</url> for full information.</p> - </item> - </list> + set as an option, it provides default values for subsequent + <seealso marker="#send/3"><c>send</c></seealso> + calls on the association specified by + <c>assoc_id</c>.</p> + <p><c>assoc_id = 0</c> (default) indicates + the whole endpoint.</p> + <p>The following fields typically must be specified by the sender:</p> + <taglist> + <tag><c>sinfo_stream</c></tag> + <item><p>Stream number (0-base) within the association + to send the messages through;</p></item> + <tag><c>sinfo_flags</c></tag> + <item><p>The following flags are recognised:</p> + <taglist> + <tag><c>unordered</c></tag> + <item>The message is to be sent unordered</item> + <tag><c>addr_over</c></tag> + <item>The address specified in + <seealso marker="#send/3"><c>send</c></seealso> + overwrites the primary peer address</item> + <tag><c>abort</c></tag> + <item>Aborts the current association without flushing any unsent + data</item> + <tag><c>eof</c></tag> + <item>Gracefully shuts down the current association, with + flushing of unsent data</item> + </taglist> + <p>Other fields are rarely used. For complete information, see + <url href="http://www.rfc-archive.org/getrfc.php?rfc=2960">RFC 2960</url> + and + <url href="http://tools.ietf.org/html/draft-ietf-tsvwg-sctpsocket-13">Sockets + API Extensions for SCTP</url>.</p></item> + </taglist> <marker id="option-sctp_events"></marker> </item> <tag><c>{sctp_events, #sctp_event_subscribe{}}</c></tag> <item> <marker id="record-sctp_event_subscribe"></marker> -<pre> #sctp_event_subscribe{ - data_io_event = true | false, - association_event = true | false, - address_event = true | false, - send_failure_event = true | false, - peer_error_event = true | false, - shutdown_event = true | false, - partial_delivery_event = true | false, - adaptation_layer_event = true | false - } </pre> + <pre> +#sctp_event_subscribe{ + data_io_event = true | false, + association_event = true | false, + address_event = true | false, + send_failure_event = true | false, + peer_error_event = true | false, + shutdown_event = true | false, + partial_delivery_event = true | false, + adaptation_layer_event = true | false +}</pre> <p>This option determines which <seealso marker="#sctp_events">SCTP Events</seealso> are to be - received (via <seealso marker="#recv/1">recv/*</seealso>) - along with the data. The only - exception is <c>data_io_event</c> which enables or disables - receiving of - <seealso marker="#record-sctp_sndrcvinfo">#sctp_sndrcvinfo{}</seealso> + received (through + <seealso marker="#recv/1"><c>recv/*</c></seealso>) + along with the data. The only exception is <c>data_io_event</c>, + which enables or disables receiving of + <seealso marker="#record-sctp_sndrcvinfo"><c>#sctp_sndrcvinfo{}</c></seealso> ancillary data, not events. By default, all flags except <c>adaptation_layer_event</c> are enabled, although <c>sctp_data_io_event</c> and @@ -873,201 +894,185 @@ </item> <tag><c>{sctp_delayed_ack_time, #sctp_assoc_value{}}</c></tag> <item> -<pre> #sctp_assoc_value{ - assoc_id = assoc_id(), - assoc_value = integer() - } </pre> + <pre> +#sctp_assoc_value{ + assoc_id = assoc_id(), + assoc_value = integer() +}</pre> <p>Rarely used. Determines the ACK time - (given by <c>assoc_value</c> in milliseconds) for - the given association or the whole endpoint + (specified by <c>assoc_value</c>, in milliseconds) for + the specified association or the whole endpoint if <c>assoc_value = 0</c> (default).</p> </item> <tag><c>{sctp_status, #sctp_status{}}</c></tag> <item> -<pre> #sctp_status{ - assoc_id = assoc_id(), - state = atom(), - rwnd = integer(), - unackdata = integer(), - penddata = integer(), - instrms = integer(), - outstrms = integer(), - fragmentation_point = integer(), - primary = #sctp_paddrinfo{} - } </pre> + <pre> +#sctp_status{ + assoc_id = assoc_id(), + state = atom(), + rwnd = integer(), + unackdata = integer(), + penddata = integer(), + instrms = integer(), + outstrms = integer(), + fragmentation_point = integer(), + primary = #sctp_paddrinfo{} +}</pre> <p>This option is read-only. It determines the status of - the SCTP association given by <c>assoc_id</c>. Possible values of - <c>state</c> follows. The state designations are mostly - self-explanatory. <c>state_empty</c> is the default which means - that no other state is active:</p> - <list type="bulleted"> - <item> - <p><c>sctp_state_empty</c></p> - </item> - <item> - <p><c>sctp_state_closed</c></p> - </item> - <item> - <p><c>sctp_state_cookie_wait</c></p> - </item> - <item> - <p><c>sctp_state_cookie_echoed</c></p> - </item> - <item> - <p><c>sctp_state_established</c></p> - </item> - <item> - <p><c>sctp_state_shutdown_pending</c></p> - </item> - <item> - <p><c>sctp_state_shutdown_sent</c></p> - </item> - <item> - <p><c>sctp_state_shutdown_received</c></p> - </item> - <item> - <p><c>sctp_state_shutdown_ack_sent</c></p> - </item> - </list> - <p>The semantics of other fields is the following:</p> - <list type="bulleted"> - <item> - <p><c>sstat_rwnd</c>: the association peer's current receiver - window size;</p> - </item> - <item> - <p><c>sstat_unackdata</c>: number of unacked data chunks;</p> - </item> - <item> - <p><c>sstat_penddata</c>: number of data chunks pending receipt;</p> - </item> - <item> - <p><c>sstat_instrms</c>: number of inbound streams;</p> - </item> - <item> - <p><c>sstat_outstrms</c>: number of outbound streams;</p> - </item> - <item> - <p><c>sstat_fragmentation_point</c>: message size at which SCTP - fragmentation will occur;</p> - </item> - <item> - <p><c>sstat_primary</c>: information on the current primary peer - address (see below for the format of <c>#sctp_paddrinfo{}</c>).</p> - </item> - </list> + the SCTP association specified by <c>assoc_id</c>. + The following are the + possible values of <c>state</c> (the state designations are mostly + self-explanatory):</p> + <taglist> + <tag><c>sctp_state_empty</c></tag> + <item>Default. Means that no other state is active.</item> + <tag><c>sctp_state_closed</c></tag> + <item></item> + <tag><c>sctp_state_cookie_wait</c></tag> + <item></item> + <tag><c>sctp_state_cookie_echoed</c></tag> + <item></item> + <tag><c>sctp_state_established</c></tag> + <item></item> + <tag><c>sctp_state_shutdown_pending</c></tag> + <item></item> + <tag><c>sctp_state_shutdown_sent</c></tag> + <item></item> + <tag><c>sctp_state_shutdown_received</c></tag> + <item></item> + <tag><c>sctp_state_shutdown_ack_sent</c></tag> + <item></item> + </taglist> + <p>Semantics of the other fields:</p> + <taglist> + <tag><c>sstat_rwnd</c></tag> + <item>Current receiver window size of the association</item> + <tag><c>sstat_unackdata</c></tag> + <item>Number of unacked data chunks</item> + <tag><c>sstat_penddata</c></tag> + <item>Number of data chunks pending receipt</item> + <tag><c>sstat_instrms</c></tag> + <item>Number of inbound streams</item> + <tag><c>sstat_outstrms</c></tag> + <item>Number of outbound streams</item> + <tag><c>sstat_fragmentation_point</c></tag> + <item>Message size at which SCTP fragmentation occurs</item> + <tag><c>sstat_primary</c></tag> + <item>Information on the current primary peer address (see below for + the format of <c>#sctp_paddrinfo{}</c>)</item> + </taglist> <marker id="option-sctp_get_peer_addr_info"></marker> </item> <tag><c>{sctp_get_peer_addr_info, #sctp_paddrinfo{}}</c></tag> <item> <marker id="record-sctp_paddrinfo"></marker> -<pre> #sctp_paddrinfo{ - assoc_id = assoc_id(), - address = {IP, Port}, - state = inactive | active | unconfirmed, - cwnd = integer(), - srtt = integer(), - rto = integer(), - mtu = integer() - } - IP = ip_address() - Port = port_number() </pre> + <pre> +#sctp_paddrinfo{ + assoc_id = assoc_id(), + address = {IP, Port}, + state = inactive | active | unconfirmed, + cwnd = integer(), + srtt = integer(), + rto = integer(), + mtu = integer() +} +IP = ip_address() +Port = port_number()</pre> <p>This option is read-only. It determines the parameters specific to - the peer's address given by <c>address</c> within the association - given by <c>assoc_id</c>. The <c>address</c> field must be set by the + the peer address specified by <c>address</c> within the association + specified by <c>assoc_id</c>. Field <c>address</c> fmust be set by the caller; all other fields are filled in on return. If <c>assoc_id = 0</c> (default), the <c>address</c> is automatically translated into the corresponding - association ID. This option is rarely used; see - <url href="http://www.rfc-archive.org/getrfc.php?rfc=2960">RFC2960</url> and - <url href="http://tools.ietf.org/html/draft-ietf-tsvwg-sctpsocket-13">Sockets API Extensions for SCTP</url> for the semantics of all fields.</p> + association ID. This option is rarely used. + For the semantics of all fields, see + <url href="http://www.rfc-archive.org/getrfc.php?rfc=2960">RFC 2960</url> + and + <url href="http://tools.ietf.org/html/draft-ietf-tsvwg-sctpsocket-13">Sockets + API Extensions for SCTP</url>.</p> </item> </taglist> </section> <section> <marker id="examples"></marker> - <title>SCTP EXAMPLES</title> - <list type="bulleted"> - <item> - <p>Example of an Erlang SCTP Server which receives SCTP messages and - prints them on the standard output:</p> -<pre> -module(sctp_server). - - -export([server/0,server/1,server/2]). - -include_lib("kernel/include/inet.hrl"). - -include_lib("kernel/include/inet_sctp.hrl"). - - server() -> - server(any, 2006). - - server([Host,Port]) when is_list(Host), is_list(Port) -> - {ok, #hostent{h_addr_list = [IP|_]}} = inet:gethostbyname(Host), - io:format("~w -> ~w~n", [Host, IP]), - server([IP, list_to_integer(Port)]). - - server(IP, Port) when is_tuple(IP) orelse IP == any orelse IP == loopback, - is_integer(Port) -> - {ok,S} = gen_sctp:open(Port, [{recbuf,65536}, {ip,IP}]), - io:format("Listening on ~w:~w. ~w~n", [IP,Port,S]), - ok = gen_sctp:listen(S, true), - server_loop(S). - - server_loop(S) -> - case gen_sctp:recv(S) of - {error, Error} -> - io:format("SCTP RECV ERROR: ~p~n", [Error]); - Data -> - io:format("Received: ~p~n", [Data]) - end, - server_loop(S). </pre> - </item> - <item> - <p>Example of an Erlang SCTP Client which interacts with the above Server. - Note that in this example, the Client creates an association with - the Server with 5 outbound streams. For this reason, sending of - "Test 0" over Stream 0 succeeds, but sending of "Test 5" - over Stream 5 fails. The client then <c>abort</c>s the association, - which results in the corresponding Event being received on - the Server side.</p> -<pre> -module(sctp_client). - - -export([client/0, client/1, client/2]). - -include_lib("kernel/include/inet.hrl"). - -include_lib("kernel/include/inet_sctp.hrl"). + <title>SCTP Examples</title> + <p>Example of an Erlang SCTP server that receives SCTP messages and + prints them on the standard output:</p> + <pre> +-module(sctp_server). + +-export([server/0,server/1,server/2]). +-include_lib("kernel/include/inet.hrl"). +-include_lib("kernel/include/inet_sctp.hrl"). + +server() -> + server(any, 2006). + +server([Host,Port]) when is_list(Host), is_list(Port) -> + {ok, #hostent{h_addr_list = [IP|_]}} = inet:gethostbyname(Host), + io:format("~w -> ~w~n", [Host, IP]), + server([IP, list_to_integer(Port)]). + +server(IP, Port) when is_tuple(IP) orelse IP == any orelse IP == loopback, + is_integer(Port) -> + {ok,S} = gen_sctp:open(Port, [{recbuf,65536}, {ip,IP}]), + io:format("Listening on ~w:~w. ~w~n", [IP,Port,S]), + ok = gen_sctp:listen(S, true), + server_loop(S). + +server_loop(S) -> + case gen_sctp:recv(S) of + {error, Error} -> + io:format("SCTP RECV ERROR: ~p~n", [Error]); + Data -> + io:format("Received: ~p~n", [Data]) + end, + server_loop(S).</pre> + <p>Example of an Erlang SCTP client interacting with the above server. + Notice that in this example the client creates an association with + the server with 5 outbound streams. Therefore, sending of + <c>"Test 0"</c> over stream 0 succeeds, but sending of <c>"Test 5"</c> + over stream 5 fails. The client then <c>abort</c>s the association, + which results in that the corresponding event is received on + the server side.</p> + <pre> +-module(sctp_client). + +-export([client/0, client/1, client/2]). +-include_lib("kernel/include/inet.hrl"). +-include_lib("kernel/include/inet_sctp.hrl"). + +client() -> + client([localhost]). + +client([Host]) -> + client(Host, 2006); - client() -> - client([localhost]). - - client([Host]) -> - client(Host, 2006); - - client([Host, Port]) when is_list(Host), is_list(Port) -> - client(Host,list_to_integer(Port)), - init:stop(). - - client(Host, Port) when is_integer(Port) -> - {ok,S} = gen_sctp:open(), - {ok,Assoc} = gen_sctp:connect - (S, Host, Port, [{sctp_initmsg,#sctp_initmsg{num_ostreams=5}}]), - io:format("Connection Successful, Assoc=~p~n", [Assoc]), - - io:write(gen_sctp:send(S, Assoc, 0, <<"Test 0">>)), - io:nl(), - timer:sleep(10000), - io:write(gen_sctp:send(S, Assoc, 5, <<"Test 5">>)), - io:nl(), - timer:sleep(10000), - io:write(gen_sctp:abort(S, Assoc)), - io:nl(), - - timer:sleep(1000), - gen_sctp:close(S). </pre> - </item> - <item> - <p>A very simple Erlang SCTP Client which uses the - connect_init API.</p> -<pre>-module(ex3). +client([Host, Port]) when is_list(Host), is_list(Port) -> + client(Host,list_to_integer(Port)), + init:stop(). + +client(Host, Port) when is_integer(Port) -> + {ok,S} = gen_sctp:open(), + {ok,Assoc} = gen_sctp:connect + (S, Host, Port, [{sctp_initmsg,#sctp_initmsg{num_ostreams=5}}]), + io:format("Connection Successful, Assoc=~p~n", [Assoc]), + + io:write(gen_sctp:send(S, Assoc, 0, <<"Test 0">>)), + io:nl(), + timer:sleep(10000), + io:write(gen_sctp:send(S, Assoc, 5, <<"Test 5">>)), + io:nl(), + timer:sleep(10000), + io:write(gen_sctp:abort(S, Assoc)), + io:nl(), + + timer:sleep(1000), + gen_sctp:close(S).</pre> + <p>A simple Erlang SCTP client that uses the <c>connect_init</c> API:</p> + <pre> +-module(ex3). -export([client/4]). -include_lib("kernel/include/inet.hrl"). @@ -1099,7 +1104,7 @@ client_loop(S, Peer1, Port1, AssocId1, Peer2, Port2, AssocId2) -> io:format("Association 2 connect result: ~p. AssocId: ~p~n", [SAC#sctp_assoc_change.state, SAC#sctp_assoc_change.assoc_id]), client_loop(S, Peer1, Port1, AssocId1, Peer2, Port2, - SAC#sctp_assoc_change.assoc_id); + SAC#sctp_assoc_change.assoc_id); {sctp, S, Peer1, Port1, Data} -> io:format("Association 1: received ~p~n", [Data]), @@ -1118,20 +1123,19 @@ client_loop(S, Peer1, Port1, AssocId1, Peer2, Port2, AssocId2) -> after 5000 -> ok - end. -</pre> - </item> - </list> + end.</pre> </section> <section> <marker id="seealso"></marker> - <title>SEE ALSO</title> - <p><seealso marker="inet">inet(3)</seealso>, - <seealso marker="gen_tcp">gen_tcp(3)</seealso>, - <seealso marker="gen_udp">gen_udp(3)</seealso>, - <url href="http://www.rfc-archive.org/getrfc.php?rfc=2960">RFC2960</url> (Stream Control Transmission Protocol), - <url href="http://tools.ietf.org/html/draft-ietf-tsvwg-sctpsocket-13">Sockets API Extensions for SCTP.</url></p> + <title>See Also</title> + <p><seealso marker="gen_tcp"><c>gen_tcp(3)</c></seealso>, + <seealso marker="gen_udp"><c>gen_udp(3)</c></seealso>, + <seealso marker="inet"><c>inet(3)</c></seealso>, + <url href="http://www.rfc-archive.org/getrfc.php?rfc=2960">RFC 2960</url> + (Stream Control Transmission Protocol), + <url href="http://tools.ietf.org/html/draft-ietf-tsvwg-sctpsocket-13">Sockets + API Extensions for SCTP</url></p> </section> </erlref> diff --git a/lib/kernel/doc/src/gen_tcp.xml b/lib/kernel/doc/src/gen_tcp.xml index c0fed31f43..919178195f 100644 --- a/lib/kernel/doc/src/gen_tcp.xml +++ b/lib/kernel/doc/src/gen_tcp.xml @@ -21,7 +21,6 @@ limitations under the License. </legalnotice> - <title>gen_tcp</title> <prepared>[email protected]</prepared> <docno></docno> @@ -29,13 +28,13 @@ <rev>A</rev> </header> <module>gen_tcp</module> - <modulesummary>Interface to TCP/IP sockets</modulesummary> + <modulesummary>Interface to TCP/IP sockets.</modulesummary> <description> - <p>The <c>gen_tcp</c> module provides functions for communicating + <p>This module provides functions for communicating with sockets using the TCP/IP protocol.</p> - <p>The following code fragment provides a simple example of + <p>The following code fragment is a simple example of a client connecting to a server at port 5678, transferring a - binary and closing the connection:</p> + binary, and closing the connection:</p> <code type="none"> client() -> SomeHostInNet = "localhost", % to make it runnable on one machine @@ -43,8 +42,8 @@ client() -> [binary, {packet, 0}]), ok = gen_tcp:send(Sock, "Some Data"), ok = gen_tcp:close(Sock).</code> - <p>At the other end a server is listening on port 5678, accepts - the connection and receives the binary:</p> + <p>At the other end, a server is listening on port 5678, accepts + the connection, and receives the binary:</p> <code type="none"> server() -> {ok, LSock} = gen_tcp:listen(5678, [binary, {packet, 0}, @@ -61,7 +60,8 @@ do_recv(Sock, Bs) -> {error, closed} -> {ok, list_to_binary(Bs)} end.</code> - <p>For more examples, see the <seealso marker="#examples">examples</seealso> section.</p> + <p>For more examples, see section + <seealso marker="#examples">Examples</seealso>.</p> </description> <datatypes> @@ -79,9 +79,10 @@ do_recv(Sock, Bs) -> </datatype> <datatype> <name>socket()</name> - <desc> - <p><marker id="type-socket"/> - As returned by accept/1,2 and connect/3,4.</p> + <desc><p><marker id="type-socket"/> + As returned by + <seealso marker="#accept/1"><c>accept/1,2</c></seealso> and + <seealso marker="#connect/3"><c>connect/3,4</c></seealso>.</p> <marker id="connect"></marker> </desc> </datatype> @@ -89,285 +90,256 @@ do_recv(Sock, Bs) -> <funcs> <func> + <name name="accept" arity="1"/> + <name name="accept" arity="2"/> + <fsummary>Accept an incoming connection request on a listening socket.</fsummary> + <type_desc variable="ListenSocket">Returned by + <seealso marker="#listen/2"><c>listen/2</c></seealso>. + </type_desc> + <desc> + <p>Accepts an incoming connection request on a listening socket. + <c><anno>Socket</anno></c> must be a socket returned from + <seealso marker="#listen/2"><c>listen/2</c></seealso>. + <c><anno>Timeout</anno></c> specifies a time-out value in + milliseconds. Defaults to <c>infinity</c>.</p> + <p>Returns:</p> + <list type="bulleted"> + <item><p><c>{ok, <anno>Socket</anno>}</c> if a connection is + established</p></item> + <item><p><c>{error, closed}</c> if <c><anno>ListenSocket</anno></c> + is closed</p></item> + <item><p><c>{error, timeout}</c> if no connection is established + within the specified time</p></item> + <item><p><c>{error, system_limit}</c> if all available ports in the + Erlang emulator are in use</p></item> + <item><p>A POSIX error value if something else goes wrong, see + <seealso marker="inet"><c>inet(3)</c></seealso> for possible + error values</p></item> + </list> + <p>Packets can be sent to the returned socket <c><anno>Socket</anno></c> + using + <seealso marker="#send/2"><c>send/2</c></seealso>. + Packets sent from the peer are delivered as messages (unless + <c>{active, false}</c> is specified in the option list for the + listening socket, in which case packets are retrieved by calling + <seealso marker="#recv/2"><c>recv/2</c></seealso>):</p> + <code type="none"> +{tcp, Socket, Data}</code> + <note> + <p>The <c>accept</c> call does + <em>not</em> have to be issued from the socket owner + process. Using version 5.5.3 and higher of the emulator, + multiple simultaneous accept calls can be issued from + different processes, which allows for a pool of acceptor + processes handling incoming connections.</p> + </note> + </desc> + </func> + + <func> + <name name="close" arity="1"/> + <fsummary>Close a TCP socket.</fsummary> + <desc> + <p>Closes a TCP socket.</p> + </desc> + </func> + + <func> <name name="connect" arity="3"/> <name name="connect" arity="4"/> - <fsummary>Connect to a TCP port</fsummary> + <fsummary>Connect to a TCP port.</fsummary> <desc> <p>Connects to a server on TCP port <c><anno>Port</anno></c> on the host - with IP address <c><anno>Address</anno></c>. The <c><anno>Address</anno></c> argument - can be either a hostname, or an IP address.</p> - <p>The available options are:</p> + with IP address <c><anno>Address</anno></c>. Argument + <c><anno>Address</anno></c> can be a hostname or an IP address.</p> + <p>The following options are available:</p> <taglist> - <tag><c>{ip, ip_address()}</c></tag> - <item> - <p>If the host has several network interfaces, this option - specifies which one to use.</p> + <tag><c>{ip, ip_address()}</c></tag> + <item><p>If the host has many network interfaces, this option + specifies which one to use.</p></item> + <tag><c>{ifaddr, ip_address()}</c></tag> + <item><p>Same as <c>{ip, ip_address()}</c>. If the host has many + network interfaces, this option specifies which one to use.</p> </item> - - <tag><c>{ifaddr, ip_address()}</c></tag> - <item> - <p>Same as <c>{ip, ip_address()}</c>. If the host has several network interfaces, this option - specifies which one to use.</p> - </item> - <tag><c>{fd, integer() >= 0}</c></tag> - <item> - <p>If a socket has somehow been connected without using - <c>gen_tcp</c>, use this option to pass the file - descriptor for it. If <c>{ip, ip_address()}</c> - and/or <c>{port, port_number()}</c> is combined with - this option the fd will be bound to the given interface - and port before connecting. If these options are not given - it is assumed that the fd is already bound appropriately. - </p> - </item> - + <item><p>If a socket has somehow been connected without using + <c>gen_tcp</c>, use this option to pass the file descriptor + for it. If <c>{ip, ip_address()}</c> and/or + <c>{port, port_number()}</c> is combined with this option, the + <c>fd</c> is bound to the specified interface and port before + connecting. If these options are not specified, it is assumed that + the <c>fd</c> is already bound appropriately.</p></item> <tag><c>inet</c></tag> - <item> - <p>Set up the socket for IPv4.</p> - </item> - - <tag><c>inet6</c></tag> - <item> - <p>Set up the socket for IPv6.</p> - </item> - + <item><p>Sets up the socket for IPv4.</p></item> + <tag><c>inet6</c></tag> + <item><p>Sets up the socket for IPv6.</p></item> <tag><c>{port, Port}</c></tag> - <item> - <p>Specify which local port number to use.</p> - </item> - - <tag><c>{tcp_module, module()}</c></tag> - <item> <p> - Override which callback module is used. Defaults to - <c>inet_tcp</c> for IPv4 and <c>inet6_tcp</c> for IPv6. - </p> - </item> - + <item><p>Specifies which local port number to use.</p></item> + <tag><c>{tcp_module, module()}</c></tag> + <item><p>Overrides which callback module is used. Defaults to + <c>inet_tcp</c> for IPv4 and <c>inet6_tcp</c> for IPv6.</p></item> <tag><c>Opt</c></tag> - <item> - <p>See - <seealso marker="inet#setopts/2">inet:setopts/2</seealso>.</p> + <item><p>See + <seealso marker="inet#setopts/2"><c>inet:setopts/2</c></seealso>.</p> </item> </taglist> <p>Packets can be sent to the returned socket <c><anno>Socket</anno></c> - using <c>send/2</c>. Packets sent from the peer are delivered - as messages:</p> + using <seealso marker="#send/2"><c>send/2</c></seealso>. + Packets sent from the peer are delivered as messages:</p> <code type="none"> {tcp, Socket, Data}</code> - <p>If the socket is in <c>{active, N}</c> mode (see <seealso marker="inet#setopts/2"> - inet:setopts/2</seealso> for details) and its message counter - drops to 0, the following message is delivered to indicate that the + <p>If the socket is in <c>{active, N}</c> mode (see + <seealso marker="inet#setopts/2"><c>inet:setopts/2</c></seealso> + for details) and its message counter drops to <c>0</c>, the following + message is delivered to indicate that the socket has transitioned to passive (<c>{active, false}</c>) mode:</p> <code type="none"> {tcp_passive, Socket}</code> <p>If the socket is closed, the following message is delivered:</p> <code type="none"> {tcp_closed, Socket}</code> - <p>If an error occurs on the socket, the following message is - delivered:</p> + <p>If an error occurs on the socket, the following message is delivered + (unless <c>{active, false}</c> is specified in the option list for + the socket, in which case packets are retrieved by calling + <seealso marker="#recv/2"><c>recv/2</c></seealso>):</p> <code type="none"> {tcp_error, Socket, Reason}</code> - <p>unless <c>{active, false}</c> is specified in the option list - for the socket, in which case packets are retrieved by - calling <c>recv/2</c>.</p> - <p>The optional <c><anno>Timeout</anno></c> parameter specifies a timeout in - milliseconds. The default value is <c>infinity</c>.</p> + <p>The optional <c><anno>Timeout</anno></c> parameter specifies a + time-out in milliseconds. Defaults to <c>infinity</c>.</p> <note> - <p>The default values for options given to <c>connect</c> can - be affected by the Kernel configuration parameter - <c>inet_default_connect_options</c>. See - <seealso marker="inet">inet(3)</seealso> for details.</p> + <p>The default values for options specified to <c>connect</c> can + be affected by the <c>Kernel</c> configuration parameter + <c>inet_default_connect_options</c>. For details, see + <seealso marker="inet"><c>inet(3)</c></seealso>.</p> </note> </desc> </func> + + <func> + <name name="controlling_process" arity="2"/> + <fsummary>Change controlling process of a socket.</fsummary> + <desc> + <p>Assigns a new controlling process <c><anno>Pid</anno></c> to + <c><anno>Socket</anno></c>. The controlling process is the process + that receives messages from the socket. If called by any other + process than the current controlling process, + <c>{error, not_owner}</c> is returned.</p> + </desc> + </func> + <func> <name name="listen" arity="2"/> - <fsummary>Set up a socket to listen on a port</fsummary> + <fsummary>Set up a socket to listen on a port.</fsummary> <desc> - <p>Sets up a socket to listen on the port <c><anno>Port</anno></c> on + <p>Sets up a socket to listen on port <c><anno>Port</anno></c> on the local host.</p> - <p>If <c><anno>Port</anno> == 0</c>, the underlying OS assigns an available - port number, use <c>inet:port/1</c> to retrieve it.</p> - <p>The available options are:</p> + <p>If <c><anno>Port</anno> == 0</c>, the underlying OS assigns an + available port number, use + <seealso marker="inet#port/1"><c>inet:port/1</c></seealso> + to retrieve it.</p> + <p>The following options are available:</p> <taglist> <tag><c>list</c></tag> - <item> - <p>Received <c>Packet</c> is delivered as a list.</p> - </item> + <item><p>Received <c>Packet</c> is delivered as a list.</p></item> <tag><c>binary</c></tag> - <item> - <p>Received <c>Packet</c> is delivered as a binary.</p> - </item> + <item><p>Received <c>Packet</c> is delivered as a binary.</p></item> <tag><c>{backlog, B}</c></tag> - <item> - <p><c>B</c> is an integer >= 0. The backlog value defaults - to 5. The backlog value defines the maximum length that - the queue of pending connections may grow to.</p> - </item> + <item><p><c>B</c> is an integer >= <c>0</c>. The backlog value + defines the maximum length that the queue of pending connections + can grow to. Defaults to <c>5</c>.</p></item> <tag><c>{ip, ip_address()}</c></tag> - <item> - <p>If the host has several network interfaces, this option - specifies which one to listen on.</p> - </item> + <item><p>If the host has many network interfaces, this option + specifies which one to listen on.</p></item> <tag><c>{port, Port}</c></tag> - <item> - <p>Specify which local port number to use.</p> - </item> + <item><p>Specifies which local port number to use.</p></item> <tag><c>{fd, Fd}</c></tag> - <item> - <p>If a socket has somehow been connected without using - <c>gen_tcp</c>, use this option to pass the file - descriptor for it.</p> + <item><p>If a socket has somehow been connected without using + <c>gen_tcp</c>, use this option to pass the file + descriptor for it.</p></item> + <tag><c>{ifaddr, ip_address()}</c></tag> + <item><p>Same as <c>{ip, ip_address()}</c>. If the host has many + network interfaces, this option specifies which one to use.</p> </item> - - <tag><c>{ifaddr, ip_address()}</c></tag> - <item> - <p>Same as <c>{ip, ip_address()}</c>. If the host has several network interfaces, this option - specifies which one to use.</p> - </item> - <tag><c>inet6</c></tag> - <item> - <p>Set up the socket for IPv6.</p> - </item> + <item><p>Sets up the socket for IPv6.</p></item> <tag><c>inet</c></tag> - <item> - <p>Set up the socket for IPv4.</p> - </item> - - <tag><c>{tcp_module, module()}</c></tag> - <item> <p> - Override which callback module is used. Defaults to - <c>inet_tcp</c> for IPv4 and <c>inet6_tcp</c> for IPv6. - </p> - </item> - + <item><p>Sets up the socket for IPv4.</p></item> + <tag><c>{tcp_module, module()}</c></tag> + <item><p>Overrides which callback module is used. Defaults to + <c>inet_tcp</c> for IPv4 and <c>inet6_tcp</c> for IPv6.</p></item> <tag><c>Opt</c></tag> - <item> - <p>See - <seealso marker="inet#setopts/2">inet:setopts/2</seealso>.</p> - </item> + <item><p>See + <seealso marker="inet#setopts/2"><c>inet:setopts/2</c></seealso>. + </p></item> </taglist> - <p>The returned socket <c><anno>ListenSocket</anno></c> can only be used in - calls to <c>accept/1,2</c>.</p> + <p>The returned socket <c><anno>ListenSocket</anno></c> can only be + used in calls to + <seealso marker="#accept/1"><c>accept/1,2</c></seealso>.</p> <note> - <p>The default values for options given to <c>listen</c> can - be affected by the Kernel configuration parameter - <c>inet_default_listen_options</c>. See - <seealso marker="inet">inet(3)</seealso> for details.</p> + <p>The default values for options specified to <c>listen</c> can + be affected by the <c>Kernel</c> configuration parameter + <c>inet_default_listen_options</c>. For details, see + <seealso marker="inet"><c>inet(3)</c></seealso>.</p> </note> </desc> </func> - <func> - <name name="accept" arity="1"/> - <name name="accept" arity="2"/> - <fsummary>Accept an incoming connection request on a listen socket</fsummary> - <type_desc variable="ListenSocket">Returned by <c>listen/2</c>. - </type_desc> - <desc> - <p>Accepts an incoming connection request on a listen socket. - <c><anno>Socket</anno></c> must be a socket returned from <c>listen/2</c>. - <c><anno>Timeout</anno></c> specifies a timeout value in ms, defaults to - <c>infinity</c>.</p> - <p>Returns <c>{ok, <anno>Socket</anno>}</c> if a connection is established, - or <c>{error, closed}</c> if <c><anno>ListenSocket</anno></c> is closed, - or <c>{error, timeout}</c> if no connection is established - within the specified time, - or <c>{error, system_limit}</c> if all available ports in the - Erlang emulator are in use. May also return a POSIX error - value if something else goes wrong, see inet(3) for possible - error values.</p> - <p>Packets can be sent to the returned socket <c><anno>Socket</anno></c> - using <c>send/2</c>. Packets sent from the peer are delivered - as messages:</p> - <code type="none"> -{tcp, Socket, Data}</code> - <p>unless <c>{active, false}</c> was specified in the option - list for the listen socket, in which case packets are - retrieved by calling <c>recv/2</c>.</p> - <note> - <p>It is worth noting that the <c>accept</c> call does - <em>not</em> have to be issued from the socket owner - process. Using version 5.5.3 and higher of the emulator, - multiple simultaneous accept calls can be issued from - different processes, which allows for a pool of acceptor - processes handling incoming connections.</p> - </note> - </desc> - </func> - <func> - <name name="send" arity="2"/> - <fsummary>Send a packet</fsummary> - <desc> - <p>Sends a packet on a socket. </p> - <p>There is no <c>send</c> call with timeout option, you use the - <c>send_timeout</c> socket option if timeouts are - desired. See the <seealso marker="#examples">examples</seealso> section.</p> - </desc> - </func> + <func> <name name="recv" arity="2"/> <name name="recv" arity="3"/> - <fsummary>Receive a packet from a passive socket</fsummary> + <fsummary>Receive a packet from a passive socket.</fsummary> <type_desc variable="HttpPacket">See the description of - <c>HttpPacket</c> in <seealso marker="erts:erlang#decode_packet/3"> - erlang:decode_packet/3</seealso>. + <c>HttpPacket</c> in + <seealso marker="erts:erlang#decode_packet/3"><c>erlang:decode_packet/3</c></seealso> + in <c>ERTS</c>. </type_desc> <desc> - <p>This function receives a packet from a socket in passive - mode. A closed socket is indicated by a return value + <p>Receives a packet from a socket in passive + mode. A closed socket is indicated by return value <c>{error, closed}</c>.</p> - <p>The <c><anno>Length</anno></c> argument is only meaningful when + <p>Argument <c><anno>Length</anno></c> is only meaningful when the socket is in <c>raw</c> mode and denotes the number of - bytes to read. If <c><anno>Length</anno></c> = 0, all available bytes are - returned. If <c><anno>Length</anno></c> > 0, exactly <c><anno>Length</anno></c> - bytes are returned, or an error; possibly discarding less - than <c><anno>Length</anno></c> bytes of data when the socket gets closed - from the other side.</p> - <p>The optional <c><anno>Timeout</anno></c> parameter specifies a timeout in - milliseconds. The default value is <c>infinity</c>.</p> - </desc> - </func> - <func> - <name name="controlling_process" arity="2"/> - <fsummary>Change controlling process of a socket</fsummary> - <desc> - <p>Assigns a new controlling process <c><anno>Pid</anno></c> to - <c><anno>Socket</anno></c>. The controlling process is the process which - receives messages from the socket. If called by any other - process than the current controlling process, - <c>{error, not_owner}</c> is returned.</p> + bytes to read. If <c><anno>Length</anno></c> is <c>0</c>, all + available bytes are returned. + If <c><anno>Length</anno></c> > <c>0</c>, exactly + <c><anno>Length</anno></c> bytes are returned, or an error; + possibly discarding less than <c><anno>Length</anno></c> bytes of + data when the socket is closed from the other side.</p> + <p>The optional <c><anno>Timeout</anno></c> parameter specifies a + time-out in milliseconds. Defaults to <c>infinity</c>.</p> </desc> </func> + <func> - <name name="close" arity="1"/> - <fsummary>Close a TCP socket</fsummary> + <name name="send" arity="2"/> + <fsummary>Send a packet.</fsummary> <desc> - <p>Closes a TCP socket.</p> + <p>Sends a packet on a socket.</p> + <p>There is no <c>send</c> call with a time-out option, use socket + option <c>send_timeout</c> if time-outs are desired. See section + <seealso marker="#examples">Examples</seealso>.</p> </desc> </func> + <func> <name name="shutdown" arity="2"/> - <fsummary>Asynchronously close a socket</fsummary> + <fsummary>Asynchronously close a socket.</fsummary> <desc> - <p>Close a socket in one or two directions.</p> - <p><c><anno>How</anno> == write</c> means closing the socket for writing, - reading from it is still possible.</p> - <p>If <c><anno>How</anno> == read</c>, or there is no outgoing + <p>Closes a socket in one or two directions.</p> + <p><c><anno>How</anno> == write</c> means closing the socket for + writing, reading from it is still possible.</p> + <p>If <c><anno>How</anno> == read</c> or there is no outgoing data buffered in the <c><anno>Socket</anno></c> port, - then the socket is shutdown immediately and any error encountered + the socket is shut down immediately and any error encountered is returned in <c><anno>Reason</anno></c>.</p> - <p>If there is data buffered in the socket port, then the attempt + <p>If there is data buffered in the socket port, the attempt to shutdown the socket is postponed until that data is written to the - kernel socket send buffer. Any errors encountered will result - in the socket being closed and <c>{error, closed}</c> being returned - on the next - <seealso marker="gen_tcp#recv/2">recv/2</seealso> or - <seealso marker="gen_tcp#send/2">send/2</seealso>.</p> - <p>To be able to handle that the peer has done a shutdown on - the write side, the <c>{exit_on_close, false}</c> option - is useful.</p> + kernel socket send buffer. If any errors are encountered, the socket + is closed and <c>{error, closed}</c> is returned on the next + <seealso marker="#recv/2"><c>recv/2</c></seealso> or + <seealso marker="#send/2"><c>send/2</c></seealso>.</p> + <p>Option <c>{exit_on_close, false}</c> is useful if the peer has done + a shutdown on the write side.</p> </desc> </func> </funcs> @@ -375,14 +347,14 @@ do_recv(Sock, Bs) -> <section> <title>Examples</title> <marker id="examples"></marker> - <p>The following example illustrates usage of the {active,once} - option and multiple accepts by implementing a server as a - number of worker processes doing accept on one single listen - socket. The start/2 function takes the number of worker - processes as well as a port number to listen for incoming - connections on. If <c>LPort</c> is specified as <c>0</c>, an - ephemeral portnumber is used, why the start function returns - the actual portnumber allocated:</p> + <p>The following example illustrates use of option + <c>{active,once}</c> and multiple accepts by implementing a server + as a number of worker processes doing accept on a single listening + socket. Function <c>start/2</c> takes the number of worker + processes and the port number on which to listen for incoming + connections. If <c>LPort</c> is specified as <c>0</c>, an + ephemeral port number is used, which is why the start function + returns the actual port number allocated:</p> <code type="none"> start(Num,LPort) -> case gen_tcp:listen(LPort,[{active, false},{packet,2}]) of @@ -421,7 +393,7 @@ loop(S) -> io:format("Socket ~w closed [~w]~n",[S,self()]), ok end.</code> - <p>A simple client could look like this:</p> + <p>Example of a simple client:</p> <code type="none"> client(PortNo,Message) -> {ok,Sock} = gen_tcp:connect("localhost",PortNo,[{active,false}, @@ -430,30 +402,29 @@ client(PortNo,Message) -> A = gen_tcp:recv(Sock,0), gen_tcp:close(Sock), A.</code> - <p>The fact that the <c>send</c> call does not accept a timeout - option, is because timeouts on send is handled through the socket + <p>The <c>send</c> call does not accept a time-out + option because time-outs on send is handled through socket option <c>send_timeout</c>. The behavior of a send operation with - no receiver is in a very high degree defined by the underlying TCP - stack, as well as the network infrastructure. If one wants to write - code that handles a hanging receiver that might eventually cause - the sender to hang on a <c>send</c> call, one writes code like - the following.</p> - <p>Consider a process that receives data from a client process that - is to be forwarded to a server on the network. The process has - connected to the server via TCP/IP and does not get any acknowledge - for each message it sends, but has to rely on the send timeout - option to detect that the other end is unresponsive. We could use - the <c>send_timeout</c> option when connecting:</p> + no receiver is mainly defined by the underlying TCP + stack and the network infrastructure. To write + code that handles a hanging receiver that can eventually cause + the sender to hang on a <c>send</c> do like the following.</p> + <p>Consider a process that receives data from a client process + to be forwarded to a server on the network. The process is + connected to the server through TCP/IP and does not get any acknowledge + for each message it sends, but has to rely on the send time-out + option to detect that the other end is unresponsive. Option + <c>send_timeout</c> can be used when connecting:</p> <code type="none"> - ... - {ok,Sock} = gen_tcp:connect(HostAddress, Port, - [{active,false}, - {send_timeout, 5000}, - {packet,2}]), - loop(Sock), % See below - ... </code> - <p>In the loop where requests are handled, we can now detect send - timeouts:</p> +... +{ok,Sock} = gen_tcp:connect(HostAddress, Port, + [{active,false}, + {send_timeout, 5000}, + {packet,2}]), + loop(Sock), % See below +...</code> + <p>In the loop where requests are handled, send time-outs can now be + detected:</p> <code type="none"> loop(Sock) -> receive @@ -477,11 +448,11 @@ loop(Sock) -> Client ! {self(), data_sent}, loop(Sock) end - end. </code> - <p>Usually it would suffice to detect timeouts on receive, as most + end.</code> + <p>Usually it suffices to detect time-outs on receive, as most protocols include some sort of acknowledgment from the server, - but if the protocol is strictly one way, the <c>send_timeout</c> - option comes in handy!</p> + but if the protocol is strictly one way, option <c>send_timeout</c> + comes in handy.</p> </section> </erlref> diff --git a/lib/kernel/doc/src/gen_udp.xml b/lib/kernel/doc/src/gen_udp.xml index 1f428ce16f..906883ed34 100644 --- a/lib/kernel/doc/src/gen_udp.xml +++ b/lib/kernel/doc/src/gen_udp.xml @@ -29,9 +29,9 @@ <rev>A</rev> </header> <module>gen_udp</module> - <modulesummary>Interface to UDP sockets</modulesummary> + <modulesummary>Interface to UDP sockets.</modulesummary> <description> - <p>The <c>gen_udp</c> module provides functions for communicating + <p>This module provides functions for communicating with sockets using the UDP protocol.</p> </description> @@ -45,175 +45,140 @@ <datatype> <name>socket()</name> <desc> - <p><marker id="type-socket"/>As returned by open/1,2.</p> + <marker id="type-socket"/> + <p>As returned by + <seealso marker="#open/1"><c>open/1,2</c></seealso>.</p> </desc> </datatype> </datatypes> <funcs> <func> + <name name="close" arity="1"/> + <fsummary>Close a UDP socket.</fsummary> + <desc> + <p>Closes a UDP socket.</p> + </desc> + </func> + + <func> + <name name="controlling_process" arity="2"/> + <fsummary>Change controlling process of a socket.</fsummary> + <desc> + <p>Assigns a new controlling process <c><anno>Pid</anno></c> to + <c><anno>Socket</anno></c>. The controlling process is the process + that receives messages from the socket. If called by any other + process than the current controlling process, + <c>{error, not_owner}</c> is returned.</p> + </desc> + </func> + + <func> <name name="open" arity="1"/> <name name="open" arity="2"/> - <fsummary>Associate a UDP port number with the process calling it</fsummary> + <fsummary>Associate a UDP port number with the process calling it.</fsummary> <desc> - <p>Associates a UDP port number (<c><anno>Port</anno></c>) with the calling - process.</p> - <p>The available options are:</p> + <p>Associates a UDP port number (<c><anno>Port</anno></c>) with the + calling process.</p> + <p>The following options are available:</p> <taglist> <tag><c>list</c></tag> - <item> - <p>Received <c>Packet</c> is delivered as a list.</p> - </item> + <item><p>Received <c>Packet</c> is delivered as a list.</p></item> <tag><c>binary</c></tag> - <item> - <p>Received <c>Packet</c> is delivered as a binary.</p> - </item> + <item><p>Received <c>Packet</c> is delivered as a binary.</p></item> <tag><c>{ip, ip_address()}</c></tag> - <item> - <p>If the host has several network interfaces, this option - specifies which one to use.</p> - </item> - - <tag><c>{ifaddr, ip_address()}</c></tag> - <item> - <p>Same as <c>{ip, ip_address()}</c>. If the host has several network interfaces, this option - specifies which one to use.</p> - </item> - - + <item><p>If the host has many network interfaces, this option + specifies which one to use.</p></item> + <tag><c>{ifaddr, ip_address()}</c></tag> + <item><p>Same as <c>{ip, ip_address()}</c>. If the host has many + network interfaces, this option specifies which one to + use.</p></item> <tag><c>{fd, integer() >= 0}</c></tag> - <item> - <p>If a socket has somehow been opened without using - <c>gen_udp</c>, use this option to pass the file - descriptor for it. If <c><anno>Port</anno></c> is not set to 0 - and/or <c>{ip, ip_address()}</c> is combined with this option - the fd will be bound to the given interface and port after being - opened. If these options are not given it is assumed that the fd - is already bound appropriately. - </p> - </item> + <item><p>If a socket has somehow been opened without using + <c>gen_udp</c>, use this option to pass the file descriptor + for it. If <c><anno>Port</anno></c> is not set to <c>0</c> and/or + <c>{ip, ip_address()}</c> is combined with this option, the + <c>fd</c> is bound to the specified interface and port after it is + being opened. If these options are not specified, it is assumed that + the <c>fd</c> is already bound appropriately.</p></item> <tag><c>inet6</c></tag> - <item> - <p>Set up the socket for IPv6.</p> - </item> + <item><p>Sets up the socket for IPv6.</p></item> <tag><c>inet</c></tag> - <item> - <p>Set up the socket for IPv4.</p> - </item> - - <tag><c>{udp_module, module()}</c></tag> - <item> <p> - Override which callback module is used. Defaults to - <c>inet_udp</c> for IPv4 and <c>inet6_udp</c> for IPv6. - </p> - </item> - + <item><p>Sets up the socket for IPv4.</p></item> + <tag><c>{udp_module, module()}</c></tag> + <item><p>Overrides which callback module is used. Defaults to + <c>inet_udp</c> for IPv4 and <c>inet6_udp</c> for IPv6.</p></item> <tag><c>{multicast_if, Address}</c></tag> - <item> - <p>Set the local device for a multicast socket.</p> - </item> - + <item><p>Sets the local device for a multicast socket.</p></item> <tag><c>{multicast_loop, true | false}</c></tag> - <item> - <p> - When <c>true</c> sent multicast packets will be looped back to the local - sockets. - </p> - </item> - + <item><p>When <c>true</c>, sent multicast packets are looped back to + the local sockets.</p></item> <tag><c>{multicast_ttl, Integer}</c></tag> - <item> - <p> - The <c>multicast_ttl</c> option changes the time-to-live (TTL) for - outgoing multicast datagrams in order to control the scope of the - multicasts. - </p> - <p> - Datagrams with a TTL of 1 are not forwarded beyond the local - network. - <br />Default: 1 - </p> - </item> - - <tag><c>{add_membership, {MultiAddress, InterfaceAddress}}</c></tag> - <item> - <p>Join a multicast group. </p> - </item> - - <tag><c>{drop_membership, {MultiAddress, InterfaceAddress}}</c></tag> - <item> - <p>Leave multicast group.</p> - </item> - + <item><p>Option <c>multicast_ttl</c> changes the time-to-live (TTL) + for outgoing multicast datagrams to control the scope of the + multicasts.</p> + <p>Datagrams with a TTL of 1 are not forwarded beyond the local + network. Defaults to <c>1</c>.</p></item> + <tag><c>{add_membership, {MultiAddress, InterfaceAddress}}</c></tag> + <item><p>Joins a multicast group.</p></item> + <tag><c>{drop_membership, {MultiAddress, InterfaceAddress}}</c></tag> + <item><p>Leaves a multicast group.</p></item> <tag><c>Opt</c></tag> - <item> - <p>See - <seealso marker="inet#setopts/2">inet:setopts/2</seealso>.</p> - </item> + <item><p>See + <seealso marker="inet#setopts/2"><c>inet:setopts/2</c></seealso>. + </p></item> </taglist> <p>The returned socket <c><anno>Socket</anno></c> is used to send - packets from this port with <c>send/4</c>. When UDP packets arrive - at the opened port, if the socket is in an active mode the packets + packets from this port with + <seealso marker="#send/4"><c>send/4</c></seealso>. + When UDP packets arrive + at the opened port, if the socket is in an active mode, the packets are delivered as messages to the controlling process:</p> <code type="none"> {udp, Socket, IP, InPortNo, Packet}</code> <p>If the socket is not in an active mode, data can be - retrieved via the <seealso marker="#recv/2">recv/2,3</seealso> calls. - Note that arriving UDP packets that are longer than - the receive buffer option specifies, might be truncated + retrieved through the + <seealso marker="#recv/2"><c>recv/2,3</c></seealso> calls. + Notice that arriving UDP packets that are longer than + the receive buffer option specifies can be truncated without warning.</p> - <p>When a socket in <c>{active, N}</c> mode (see <seealso marker="inet#setopts/2"> - inet:setopts/2</seealso> for details) transitions to passive - (<c>{active, false}</c>) mode, the controlling process is notified by a - message of the following form:</p> + <p>When a socket in <c>{active, N}</c> mode (see + <seealso marker="inet#setopts/2"><c>inet:setopts/2</c></seealso> + for details), transitions to passive (<c>{active, false}</c>) mode, + the controlling process is notified by a message of the following + form:</p> <code type="none"> {udp_passive, Socket}</code> <p><c>IP</c> and <c>InPortNo</c> define the address from which - <c>Packet</c> came. <c>Packet</c> is a list of bytes if - the option <c>list</c> was specified. <c>Packet</c> is a - binary if the option <c>binary</c> was specified.</p> + <c>Packet</c> comes. <c>Packet</c> is a list of bytes if + option <c>list</c> is specified. <c>Packet</c> is a + binary if option <c>binary</c> is specified.</p> <p>Default value for the receive buffer option is <c>{recbuf, 8192}</c>.</p> - <p>If <c><anno>Port</anno> == 0</c>, the underlying OS assigns a free UDP - port, use <c>inet:port/1</c> to retrieve it.</p> - </desc> - </func> - <func> - <name name="send" arity="4"/> - <fsummary>Send a packet</fsummary> - <desc> - <p>Sends a packet to the specified address and port. - The <c><anno>Address</anno></c> argument can be either a hostname, or an - IP address.</p> + <p>If <c><anno>Port</anno> == 0</c>, the underlying OS assigns a free + UDP port, use + <seealso marker="inet#port/1"><c>inet:port/1</c></seealso> + to retrieve it.</p> </desc> </func> + <func> <name name="recv" arity="2"/> <name name="recv" arity="3"/> - <fsummary>Receive a packet from a passive socket</fsummary> - <desc> - <p>This function receives a packet from a socket in passive - mode.</p> - <p>The optional <c><anno>Timeout</anno></c> parameter specifies a timeout in - milliseconds. The default value is <c>infinity</c>.</p> - </desc> - </func> - <func> - <name name="controlling_process" arity="2"/> - <fsummary>Change controlling process of a socket</fsummary> + <fsummary>Receive a packet from a passive socket.</fsummary> <desc> - <p>Assigns a new controlling process <c><anno>Pid</anno></c> to - <c><anno>Socket</anno></c>. The controlling process is the process which - receives messages from the socket. If called by any other - process than the current controlling process, - <c>{error, not_owner}</c> is returned.</p> + <p>Receives a packet from a socket in passive mode. Optional parameter + <c><anno>Timeout</anno></c> specifies a time-out in milliseconds. + Defaults to <c>infinity</c>.</p> </desc> </func> + <func> - <name name="close" arity="1"/> - <fsummary>Close a UDP socket</fsummary> + <name name="send" arity="4"/> + <fsummary>Send a packet.</fsummary> <desc> - <p>Closes a UDP socket.</p> + <p>Sends a packet to the specified address and port. Argument + <c><anno>Address</anno></c> can be a hostname or an IP address.</p> </desc> </func> </funcs> diff --git a/lib/kernel/doc/src/global.xml b/lib/kernel/doc/src/global.xml index 9ce02a99ed..4442741f54 100644 --- a/lib/kernel/doc/src/global.xml +++ b/lib/kernel/doc/src/global.xml @@ -29,82 +29,67 @@ <rev></rev> </header> <module>global</module> - <modulesummary>A Global Name Registration Facility</modulesummary> + <modulesummary>A global name registration facility.</modulesummary> <description> - <p>This documentation describes the Global module which consists - of the following functionalities:</p> - + <p>This module consists of the following services:</p> <list type="bulleted"> - <item>registration of global names;</item> - <item>global locks;</item> - <item>maintenance of the fully connected network.</item> + <item>Registration of global names</item> + <item>Global locks</item> + <item>Maintenance of the fully connected network</item> </list> - - <p>These services are controlled via the process - <c>global_name_server</c> which exists on every node. The global - name server is started automatically when a node is started. + <p>These services are controlled through the process + <c>global_name_server</c> that exists on every node. The global + name server starts automatically when a node is started. With the term <em>global</em> is meant over a system consisting - of several Erlang nodes.</p> - + of many Erlang nodes.</p> <p>The ability to globally register names is a central concept in the programming of distributed Erlang systems. In this module, the equivalent of the <c>register/2</c> and <c>whereis/1</c> - BIFs (for local name registration) are implemented, but for a + BIFs (for local name registration) are provided, but for a network of Erlang nodes. A registered name is an alias for a process identifier (pid). The global name server monitors - globally registered pids. If a process terminates, the name will - also be globally unregistered.</p> - + globally registered pids. If a process terminates, the name is + also globally unregistered.</p> <p>The registered names are stored in replica global name tables on every node. There is no central storage point. Thus, the translation of a name to a pid is fast, as it is always done - locally. When any action in taken which results in a change to - the global name table, all tables on other nodes are automatically - updated.</p> - + locally. For any action resulting in a change to the global name table, + all tables on other nodes are automatically updated.</p> <p>Global locks have lock identities and are set on a specific - resource. For instance, the specified resource could be a pid. + resource. For example, the specified resource can be a pid. When a global lock is set, access to the locked resource is - denied for all other resources other than the lock requester.</p> - - <p>Both the registration and lock functionalities are atomic. All - nodes involved in these actions will have the same view of + denied for all resources other than the lock requester.</p> + <p>Both the registration and lock services are atomic. + All nodes involved in these actions have the same view of the information.</p> - <p>The global name server also performs the critical task of - continuously monitoring changes in node configuration: if a node - which runs a globally registered process goes down, the name - will be globally unregistered. To this end the global name + continuously monitoring changes in node configuration. If a node + that runs a globally registered process goes down, the name + is globally unregistered. To this end, the global name server subscribes to <c>nodeup</c> and <c>nodedown</c> messages - sent from the <c>net_kernel</c> module. Relevant Kernel + sent from module <c>net_kernel</c>. Relevant Kernel application variables in this context are <c>net_setuptime</c>, <c>net_ticktime</c>, and <c>dist_auto_connect</c>. See also - <seealso marker="kernel_app#net_setuptime">kernel(6)</seealso>.</p> - - <p>The name server will also maintain a fully connected network. For + <seealso marker="kernel_app#net_setuptime"><c>kernel(6)</c></seealso>.</p> + <p>The name server also maintains a fully connected network. For example, if node <c>N1</c> connects to node <c>N2</c> (which is already connected to <c>N3</c>), the global name servers on the - nodes <c>N1</c> and <c>N3</c> will make sure that also <c>N1</c> - and <c>N3</c> are connected. If this is not desired, the command - line flag <c>-connect_all false</c> can be used (see also - <seealso marker="erts:erl#connect_all">erl(1)</seealso>). In - this case the name registration facility cannot be used, but the - lock mechanism will still work.</p> - + nodes <c>N1</c> and <c>N3</c> ensure that also <c>N1</c> + and <c>N3</c> are connected. If this is not desired, + command-line flag <c>-connect_all false</c> can be used (see also + <seealso marker="erts:erl#connect_all"><c>erl(1)</c></seealso>). + In this case, the name registration service cannot be used, but the + lock mechanism still works.</p> <p>If the global name server fails to connect nodes (<c>N1</c> and - <c>N3</c> in the example above) a warning event is sent to the + <c>N3</c> in the example), a warning event is sent to the error logger. The presence of such an event does not exclude the - possibility that the nodes will later connect--one can for - example try the command <c>rpc:call(N1, net_adm, ping, [N2])</c> in - the Erlang shell--but it indicates some kind of problem with - the network.</p> - + nodes to connect later (you can, for + example, try command <c>rpc:call(N1, net_adm, ping, [N2])</c> in + the Erlang shell), but it indicates a network problem.</p> <note> - <p>If the fully connected network is not set up properly, the - first thing to try is to increase the value of - <c>net_setuptime</c>.</p> + <p>If the fully connected network is not set up properly, try + first to increase the value of <c>net_setuptime</c>.</p> </note> - </description> <datatypes> @@ -117,7 +102,7 @@ <func> <name name="del_lock" arity="1"/> <name name="del_lock" arity="2"/> - <fsummary>Delete a lock</fsummary> + <fsummary>Delete a lock.</fsummary> <desc> <p>Deletes the lock <c><anno>Id</anno></c> synchronously.</p> </desc> @@ -125,11 +110,13 @@ <func> <name name="notify_all_name" arity="3"/> - <fsummary>Name resolving function that notifies both pids</fsummary> + <fsummary>Name resolving function that notifies both pids.</fsummary> <desc> - <p>This function can be used as a name resolving function for - <c>register_name/3</c> and <c>re_register_name/3</c>. It - unregisters both pids, and sends the message + <p>Can be used as a name resolving function for + <seealso marker="#register_name/3"><c>register_name/3</c></seealso> + and + <seealso marker="#re_register_name/3"><c>re_register_name/3</c></seealso>.</p> + <p>The function unregisters both pids and sends the message <c>{global_name_conflict, <anno>Name</anno>, OtherPid}</c> to both processes.</p> </desc> @@ -137,85 +124,97 @@ <func> <name name="random_exit_name" arity="3"/> - <fsummary>Name resolving function that kills one pid</fsummary> + <fsummary>Name resolving function that kills one pid.</fsummary> <desc> - <p>This function can be used as a name resolving function for - <c>register_name/3</c> and <c>re_register_name/3</c>. It - randomly chooses one of the pids for registration and kills - the other one.</p> + <p>Can be used as a name resolving function for + <seealso marker="#register_name/3"><c>register_name/3</c></seealso> + and + <seealso marker="#re_register_name/3"><c>re_register_name/3</c></seealso>.</p> + <p>The function randomly selects one of the pids for registration and + kills the other one.</p> </desc> </func> <func> <name name="random_notify_name" arity="3"/> - <fsummary>Name resolving function that notifies one pid</fsummary> + <fsummary>Name resolving function that notifies one pid.</fsummary> <desc> - <p>This function can be used as a name resolving function for - <c>register_name/3</c> and <c>re_register_name/3</c>. It - randomly chooses one of the pids for registration, and sends - the message <c>{global_name_conflict, <anno>Name</anno>}</c> to the other - pid.</p> + <p>Can be used as a name resolving function for + <seealso marker="#register_name/3"><c>register_name/3</c></seealso> + and + <seealso marker="#re_register_name/3"><c>re_register_name/3</c></seealso>.</p> + <p>The function randomly selects one of the pids for registration, and + sends the message <c>{global_name_conflict, <anno>Name</anno>}</c> to + the other pid.</p> + </desc> + </func> + + <func> + <name name="re_register_name" arity="2"/> + <name name="re_register_name" arity="3"/> + <fsummary>Atomically re-register a name.</fsummary> + <type name="method"/> + <type_desc name="method">{<c>Module</c>, <c>Function</c>} + is also allowed. + </type_desc> + <desc> + <p>Atomically changes the registered name <c><anno>Name</anno></c> on + all nodes to refer to <c><anno>Pid</anno></c>.</p> + <p>Function <c><anno>Resolve</anno></c> has the same behavior as in + <seealso marker="#register_name/2"><c>register_name/2,3</c></seealso>. + </p> </desc> </func> <func> <name name="register_name" arity="2"/> <name name="register_name" arity="3"/> - <fsummary>Globally register a name for a pid</fsummary> + <fsummary>Globally register a name for a pid.</fsummary> <type name="method"/> - <type_desc name="method">{<c>Module</c>, <c>Function</c>} - is currently also allowed for backward compatibility, but its use is - deprecated + <type_desc name="method">{<c>Module</c>, <c>Function</c>} is also + allowed for backward compatibility, but its use is deprecated. </type_desc> <desc> - <p>Globally associates the name <c><anno>Name</anno></c> with a pid, that is, - Globally notifies all nodes of a new global name in a network + <p>Globally associates name <c><anno>Name</anno></c> with a pid, that + is, globally notifies all nodes of a new global name in a network of Erlang nodes.</p> - <p>When new nodes are added to the network, they are informed of the globally registered names that already exist. The network is also informed of any global names in newly connected nodes. If any name clashes are discovered, - the <c><anno>Resolve</anno></c> function is called. Its purpose is to + function <c><anno>Resolve</anno></c> is called. Its purpose is to decide which pid is correct. If the function crashes, or returns anything other than one of the pids, the name is unregistered. This function is called once for each name clash.</p> - <warning> <p>If you plan to change code without restarting your system, you must use an external fun (<c>fun Module:Function/Arity</c>) - as the <c><anno>Resolve</anno></c> function; if you use a - local fun you can never replace the code for the module that - the fun belongs to. - </p> + as function <c><anno>Resolve</anno></c>. If you use a + local fun, you can never replace the code for the module that + the fun belongs to.</p> </warning> - - <p>There are three pre-defined resolve functions: + <p>Three predefined resolve functions exist: <c>random_exit_name/3</c>, <c>random_notify_name/3</c>, and - <c>notify_all_name/3</c>. If no <c><anno>Resolve</anno></c> function is - defined, <c>random_exit_name</c> is used. This means that one - of the two registered processes will be selected as correct + <c>notify_all_name/3</c>. If no <c><anno>Resolve</anno></c> function + is defined, <c>random_exit_name</c> is used. This means that one + of the two registered processes is selected as correct while the other is killed.</p> - - <p>This function is completely synchronous. This means that + <p>This function is completely synchronous, that is, when this function returns, the name is either registered on all nodes or none.</p> - <p>The function returns <c>yes</c> if successful, <c>no</c> if it fails. For example, <c>no</c> is returned if an attempt is made to register an already registered process or to register a process with a name that is already in use.</p> - <note> - <p>Releases up to and including OTP R10 did not check if the - process was already registered. As a consequence the - global name table could become inconsistent. The old + <p>Releases up to and including Erlang/OTP R10 did not check if the + process was already registered. The global name table could + therefore become inconsistent. The old (buggy) behavior can be chosen by giving the Kernel application variable <c>global_multi_name_action</c> the value <c>allow</c>.</p> </note> - <p>If a process with a registered name dies, or the node goes down, the name is unregistered on all nodes.</p> </desc> @@ -223,38 +222,20 @@ <func> <name name="registered_names" arity="0"/> - <fsummary>All globally registered names</fsummary> - <desc> - <p>Returns a lists of all globally registered names.</p> - </desc> - </func> - - <func> - <name name="re_register_name" arity="2"/> - <name name="re_register_name" arity="3"/> - <fsummary>Atomically re-register a name</fsummary> - <type name="method"/> - <type_desc name="method">{<c>Module</c>, <c>Function</c>} - is also allowed - </type_desc> + <fsummary>All globally registered names.</fsummary> <desc> - <p>Atomically changes the registered name <c><anno>Name</anno></c> on all - nodes to refer to <c><anno>Pid</anno></c>.</p> - - <p>The <c><anno>Resolve</anno></c> function has the same behavior as in - <c>register_name/2,3</c>.</p> + <p>Returns a list of all globally registered names.</p> </desc> </func> <func> <name name="send" arity="2"/> - <fsummary>Send a message to a globally registered pid</fsummary> + <fsummary>Send a message to a globally registered pid.</fsummary> <desc> - <p>Sends the message <c><anno>Msg</anno></c> to the pid globally registered + <p>Sends message <c><anno>Msg</anno></c> to the pid globally registered as <c><anno>Name</anno></c>.</p> - - <p>Failure: If <c><anno>Name</anno></c> is not a globally registered - name, the calling function will exit with reason + <p>If <c><anno>Name</anno></c> is not a globally registered + name, the calling function exits with reason <c>{badarg, {<anno>Name</anno>, <anno>Msg</anno>}}</c>.</p> </desc> </func> @@ -263,7 +244,7 @@ <name name="set_lock" arity="1"/> <name name="set_lock" arity="2"/> <name name="set_lock" arity="3"/> - <fsummary>Set a lock on the specified nodes</fsummary> + <fsummary>Set a lock on the specified nodes.</fsummary> <type name="id"/> <type name="retries"/> <desc> @@ -271,50 +252,48 @@ are specified) on <c><anno>ResourceId</anno></c> for <c><anno>LockRequesterId</anno></c>. If a lock already exists on <c><anno>ResourceId</anno></c> for another requester than - <c><anno>LockRequesterId</anno></c>, and <c><anno>Retries</anno></c> is not equal to 0, - the process sleeps for a while and will try to execute - the action later. When <c><anno>Retries</anno></c> attempts have been made, - <c>false</c> is returned, otherwise <c>true</c>. If - <c><anno>Retries</anno></c> is <c>infinity</c>, <c>true</c> is eventually - returned (unless the lock is never released).</p> - - <p>If no value for <c><anno>Retries</anno></c> is given, <c>infinity</c> is - used.</p> - + <c><anno>LockRequesterId</anno></c>, and <c><anno>Retries</anno></c> + is not equal to <c>0</c>, the process sleeps for a while and tries + to execute the action later. When <c><anno>Retries</anno></c> + attempts have been made, <c>false</c> is returned, otherwise + <c>true</c>. If <c><anno>Retries</anno></c> is <c>infinity</c>, + <c>true</c> is eventually returned (unless the lock is never + released).</p> + <p>If no value for <c><anno>Retries</anno></c> is specified, + <c>infinity</c> is used.</p> <p>This function is completely synchronous.</p> - - <p>If a process which holds a lock dies, or the node goes + <p>If a process that holds a lock dies, or the node goes down, the locks held by the process are deleted.</p> - <p>The global name server keeps track of all processes sharing the same lock, that is, if two processes set the same lock, both processes must delete the lock.</p> - <p>This function does not address the problem of a deadlock. A deadlock can never occur as long as processes only lock one - resource at a time. But if some processes try to lock two or - more resources, a deadlock may occur. It is up to the + resource at a time. A deadlock can occur if some processes + try to lock two or more resources. It is up to the application to detect and rectify a deadlock.</p> - <note> - <p>Some values of <c><anno>ResourceId</anno></c> should be avoided or - Erlang/OTP will not work properly. A list of resources to - avoid: <c>global</c>, <c>dist_ac</c>, - <c>mnesia_table_lock</c>, <c>mnesia_adjust_log_writes</c>, - <c>pg2</c>.</p> + <p>Avoid the following values of <c><anno>ResourceId</anno></c>, + otherwise Erlang/OTP does not work properly:</p> + <list type="bulleted"> + <item><c>dist_ac</c></item> + <item><c>global</c></item> + <item><c>mnesia_adjust_log_writes</c></item> + <item><c>mnesia_table_lock</c></item> + <item><c>pg2</c></item> + </list> </note> - </desc> </func> <func> <name name="sync" arity="0"/> - <fsummary>Synchronize the global name server</fsummary> + <fsummary>Synchronize the global name server.</fsummary> <desc> <p>Synchronizes the global name server with all nodes known to - this node. These are the nodes which are returned from + this node. These are the nodes that are returned from <c>erlang:nodes()</c>. When this function returns, - the global name server will receive global information from + the global name server receives global information from all nodes. This function can be called when new nodes are added to the network.</p> <p>The only possible error reason <c>Reason</c> is @@ -326,24 +305,25 @@ <name name="trans" arity="2"/> <name name="trans" arity="3"/> <name name="trans" arity="4"/> - <fsummary>Micro transaction facility</fsummary> + <fsummary>Micro transaction facility.</fsummary> <type name="retries"/> <type name="trans_fun"/> <desc> - <p>Sets a lock on <c><anno>Id</anno></c> (using <c>set_lock/3</c>). If this - succeeds, <c><anno>Fun</anno>()</c> is evaluated and the result <c><anno>Res</anno></c> - is returned. Returns <c>aborted</c> if the lock attempt - failed. If <c><anno>Retries</anno></c> is set to <c>infinity</c>, - the transaction will not abort.</p> - - <p><c>infinity</c> is the default setting and will be used if - no value is given for <c><anno>Retries</anno></c>.</p> + <p>Sets a lock on <c><anno>Id</anno></c> (using + <seealso marker="#set_lock/3"><c>set_lock/3</c></seealso>). + If this succeeds, <c><anno>Fun</anno>()</c> is evaluated and the + result <c><anno>Res</anno></c> + is returned. Returns <c>aborted</c> if the lock attempt fails. + If <c><anno>Retries</anno></c> is set to <c>infinity</c>, + the transaction does not abort.</p> + <p><c>infinity</c> is the default setting and is used if + no value is specified for <c><anno>Retries</anno></c>.</p> </desc> </func> <func> <name name="unregister_name" arity="1"/> - <fsummary>Remove a globally registered name for a pid</fsummary> + <fsummary>Remove a globally registered name for a pid.</fsummary> <desc> <p>Removes the globally registered name <c><anno>Name</anno></c> from the network of Erlang nodes.</p> @@ -352,7 +332,7 @@ <func> <name name="whereis_name" arity="1"/> - <fsummary>Get the pid with a given globally registered name</fsummary> + <fsummary>Get the pid with a specified globally registered name.</fsummary> <desc> <p>Returns the pid with the globally registered name <c><anno>Name</anno></c>. Returns <c>undefined</c> if the name is not @@ -363,8 +343,8 @@ <section> <title>See Also</title> - <p><seealso marker="global_group">global_group(3)</seealso>, - <seealso marker="net_kernel">net_kernel(3)</seealso></p> + <p><seealso marker="global_group"><c>global_group(3)</c></seealso>, + <seealso marker="net_kernel"><c>net_kernel(3)</c></seealso></p> </section> </erlref> diff --git a/lib/kernel/doc/src/global_group.xml b/lib/kernel/doc/src/global_group.xml index 3a993fc9e6..8f947b9adf 100644 --- a/lib/kernel/doc/src/global_group.xml +++ b/lib/kernel/doc/src/global_group.xml @@ -26,22 +26,22 @@ <prepared>Esko Vierumäki</prepared> <docno></docno> <date>1998-12-18</date> - <rev>b</rev> + <rev>B</rev> </header> <module>global_group</module> - <modulesummary>Grouping Nodes to Global Name Registration Groups</modulesummary> + <modulesummary>Grouping nodes to global name registration groups.</modulesummary> <description> - <p>The global group function makes it possible to group the nodes - in a system into partitions, each partition having its own global - name space, refer to <c>global(3)</c>. These partitions are - called global groups.</p> - <p>The main advantage of dividing systems to global groups is that + <p>This module makes it possible to partition the nodes of a + system into <em>global groups</em>. Each global group has its own + global namespace, see <seealso marker="global"> + <c>global(3)</c></seealso>.</p> + <p>The main advantage of dividing systems into global groups is that the background load decreases while the number of nodes to be updated is reduced when manipulating globally registered names.</p> <p>The Kernel configuration parameter <c>global_groups</c> defines the global groups (see also - <seealso marker="kernel_app">kernel(6)</seealso>, - <seealso marker="config">config(4)</seealso>:</p> + <seealso marker="kernel_app#global_groups"><c>kernel(6)</c></seealso> + and <seealso marker="config"><c>config(4)</c></seealso>):</p> <code type="none"> {global_groups, [GroupTuple :: group_tuple()]}</code> <p>For the processes and nodes to run smoothly using the global @@ -54,22 +54,24 @@ </item> <item> <p>All involved nodes must agree on the global group definition, - or the behavior of the system is undefined.</p> + otherwise the behavior of the system is undefined.</p> </item> <item> - <p><em>All</em> nodes in the system should belong to exactly + <p><em>All</em> nodes in the system must belong to exactly one global group.</p> </item> </list> - <p>In the following description, a <em>group node</em> is a node + <p>In the following descriptions, a <em>group node</em> is a node belonging to the same global group as the local node.</p> </description> - <datatypes> + + <datatypes> <datatype> <name name="group_tuple"/> <desc> <p>A <c>GroupTuple</c> without <c>PublishType</c> is the same as a - <c>GroupTuple</c> with <c>PublishType == normal</c>.</p> + <c>GroupTuple</c> with <c>PublishType</c> equal to <c>normal</c>. + </p> </desc> </datatype> <datatype> @@ -78,52 +80,57 @@ <datatype> <name name="publish_type"/> <desc> - <p>A node started with the command line flag <c>-hidden</c>, see - <seealso marker="erts:erl">erl(1)</seealso>, is said to be a - <em>hidden</em> node. A hidden node will establish hidden + <p>A node started with command-line flag <c>-hidden</c> (see + <seealso marker="erts:erl"><c>erl(1)</c></seealso>) is said + to be a <em>hidden</em> node. A hidden node establishes hidden connections to nodes not part of the same global group, but normal (visible) connections to nodes part of the same global group.</p> - <p>A global group defined with <c>PublishType == hidden</c>, is - said to be a hidden global group. All nodes in a hidden global - group are hidden nodes, regardless if they are started with - the <c>-hidden</c> command line flag or not.</p> + <p>A global group defined with <c>PublishType</c> equal to + <c>hidden</c> is said to be a hidden global group. + All nodes in a hidden global + group are hidden nodes, whether they are started with + command-line flag <c>-hidden</c> or not.</p> </desc> </datatype> <datatype> <name name="name"/> <desc><p>A registered name.</p></desc> </datatype> + <datatype> <name name="where"/> </datatype> </datatypes> + <funcs> <func> <name name="global_groups" arity="0"/> - <fsummary>Return the global group names</fsummary> + <fsummary>Return the global group names.</fsummary> <desc> - <p>Returns a tuple containing the name of the global group + <p>Returns a tuple containing the name of the global group that the local node belongs to, and the list of all other known group names. Returns <c>undefined</c> if no global groups are defined.</p> </desc> </func> + <func> <name name="info" arity="0"/> - <fsummary>Information about global groups</fsummary> + <fsummary>Information about global groups.</fsummary> <type name="info_item"/> <type name="sync_state"/> <desc> <p>Returns a list containing information about the global - groups. Each element of the list is a tuple. The order of - the tuples is not defined.</p> + groups. Each list element is a tuple. The order of + the tuples is undefined.</p> <taglist> <tag><c>{state, <anno>State</anno>}</c></tag> <item> <p>If the local node is part of a global group, - <c><anno>State</anno> == synced</c>. If no global groups are defined, - <c><anno>State</anno> == no_conf</c>.</p> + <c><anno>State</anno></c> is equal to <c>synced</c>. + If no global groups are defined, + <c><anno>State</anno></c> is equal to <c>no_conf</c>.</p> </item> <tag><c>{own_group_name, <anno>GroupName</anno>}</c></tag> <item> @@ -152,117 +159,131 @@ <tag><c>{other_groups, <anno>Groups</anno>}</c></tag> <item> <p><c><anno>Groups</anno></c> is a list of tuples - <c>{<anno>GroupName</anno>, <anno>Nodes</anno>}</c>, specifying the name and nodes + <c>{<anno>GroupName</anno>, <anno>Nodes</anno>}</c>, + specifying the name and nodes of the other global groups.</p> </item> <tag><c>{monitoring, <anno>Pids</anno>}</c></tag> <item> - <p>A list of pids, specifying the processes which have + <p>A list of pids, specifying the processes that have subscribed to <c>nodeup</c> and <c>nodedown</c> messages.</p> </item> </taglist> </desc> </func> + <func> <name name="monitor_nodes" arity="1"/> - <fsummary>Subscribe to node status changes</fsummary> + <fsummary>Subscribe to node status changes.</fsummary> <desc> - <p>Depending on <c><anno>Flag</anno></c>, the calling process starts - subscribing (<c><anno>Flag</anno> == true</c>) or stops subscribing - (<c><anno>Flag</anno> == false</c>) to node status change messages.</p> - <p>A process which has subscribed will receive the messages + <p>Depending on <c><anno>Flag</anno></c>, the calling process + starts subscribing (<c><anno>Flag</anno></c> equal to + <c>true</c>) or stops subscribing (<c><anno>Flag</anno></c> + equal to <c>false</c>) to node status change messages.</p> + <p>A process that has subscribed receives the messages <c>{nodeup, Node}</c> and <c>{nodedown, Node}</c> when a group node connects or disconnects, respectively.</p> </desc> </func> + <func> <name name="own_nodes" arity="0"/> - <fsummary>Return the group nodes</fsummary> + <fsummary>Return the group nodes.</fsummary> <desc> <p>Returns the names of all group nodes, regardless of their current status.</p> </desc> </func> + <func> <name name="registered_names" arity="1"/> - <fsummary>Return globally registered names</fsummary> + <fsummary>Return globally registered names.</fsummary> <desc> - <p>Returns a list of all names which are globally registered + <p>Returns a list of all names that are globally registered on the specified node or in the specified global group.</p> </desc> </func> + <func> <name name="send" arity="2"/> <name name="send" arity="3"/> - <fsummary>Send a message to a globally registered pid</fsummary> + <fsummary>Send a message to a globally registered pid.</fsummary> <desc> <p>Searches for <c><anno>Name</anno></c>, globally registered on - the specified node or in the specified global group, or -- - if the <c><anno>Where</anno></c> argument is not provided -- in any global - group. The global groups are searched in the order in which - they appear in the value of the <c>global_groups</c> - configuration parameter.</p> - <p>If <c><anno>Name</anno></c> is found, the message <c><anno>Msg</anno></c> is sent to + the specified node or in the specified global group, or + (if argument <c><anno>Where</anno></c> is not provided) in any + global group. The global groups are searched in the order that + they appear in the value of configuration parameter + <c>global_groups</c>.</p> + <p>If <c><anno>Name</anno></c> is found, message + <c><anno>Msg</anno></c> is sent to the corresponding pid. The pid is also the return value of the function. If the name is not found, the function returns <c>{badarg, {<anno>Name</anno>, <anno>Msg</anno>}}</c>.</p> </desc> </func> + <func> <name name="sync" arity="0"/> - <fsummary>Synchronize the group nodes</fsummary> + <fsummary>Synchronize the group nodes.</fsummary> <desc> <p>Synchronizes the group nodes, that is, the global name - servers on the group nodes. Also check the names globally + servers on the group nodes. Also checks the names globally registered in the current global group and unregisters them on any known node not part of the group.</p> <p>If synchronization is not possible, an error report is sent - to the error logger (see also <c>error_logger(3)</c>).</p> - <p>Failure: - <c>{error, {'invalid global_groups definition', Bad}}</c> if - the <c>global_groups</c> configuration parameter has an + to the error logger (see also + <seealso marker="error_logger"><c>error_logger(3)</c></seealso>. + </p> + <p>Returns <c>{error, {'invalid global_groups definition', Bad}}</c> + if configuration parameter <c>global_groups</c> has an invalid value <c>Bad</c>.</p> </desc> </func> + <func> <name name="whereis_name" arity="1"/> <name name="whereis_name" arity="2"/> - <fsummary>Get the pid with a given globally registered name</fsummary> + <fsummary>Get the pid with a specified globally registered name.</fsummary> <desc> <p>Searches for <c><anno>Name</anno></c>, globally registered on - the specified node or in the specified global group, or -- if - the <c><anno>Where</anno></c> argument is not provided -- in any global - group. The global groups are searched in the order in which - they appear in the value of the <c>global_groups</c> - configuration parameter.</p> - <p>If <c><anno>Name</anno></c> is found, the corresponding pid is returned. - If the name is not found, the function returns + the specified node or in the specified global group, or + (if argument <c><anno>Where</anno></c> is not provided) in any global + group. The global groups are searched in the order that + they appear in the value of configuration parameter + <c>global_groups</c>.</p> + <p>If <c><anno>Name</anno></c> is found, the corresponding pid is + returned. If the name is not found, the function returns <c>undefined</c>.</p> </desc> </func> </funcs> <section> - <title>NOTE</title> - <p>In the situation where a node has lost its connections to other - nodes in its global group, but has connections to nodes in other - global groups, a request from another global group may produce an - incorrect or misleading result. For example, the isolated node may - not have accurate information about registered names in its - global group.</p> - <p>Note also that the <c>send/2,3</c> function is not secure.</p> - <p>Distribution of applications is highly dependent of the global - group definitions. It is not recommended that an application is - distributed over several global groups of the obvious reason that - the registered names may be moved to another global group at - failover/takeover. There is nothing preventing doing this, but - the application code must in such case handle the situation.</p> + <title>Notes</title> + <list type="bulleted"> + <item><p>In the situation where a node has lost its connections to other + nodes in its global group, but has connections to nodes in other + global groups, a request from another global group can produce an + incorrect or misleading result. For example, the isolated node can + have inaccurate information about registered names in its + global group.</p></item> + <item><p>Function + <seealso marker="#send/2"><c>send/2,3</c></seealso> + is not secure.</p></item> + <item><p>Distribution of applications is highly dependent of the global + group definitions. It is not recommended that an application is + distributed over many global groups, as + the registered names can be moved to another global group at + failover/takeover. Nothing prevents this to be done, but + the application code must then handle the situation.</p></item> + </list> </section> <section> - <title>SEE ALSO</title> - <p><seealso marker="erts:erl">erl(1)</seealso>, - <seealso marker="global">global(3)</seealso></p> + <title>See Also</title> + <p><seealso marker="global"><c>global(3)</c></seealso>, + <seealso marker="erts:erl"><c>erl(1)</c></seealso></p> </section> </erlref> diff --git a/lib/kernel/doc/src/heart.xml b/lib/kernel/doc/src/heart.xml index 2bd8fef0df..c587e39345 100644 --- a/lib/kernel/doc/src/heart.xml +++ b/lib/kernel/doc/src/heart.xml @@ -29,93 +29,80 @@ <rev>A</rev> </header> <module>heart</module> - <modulesummary>Heartbeat Monitoring of an Erlang Runtime System</modulesummary> + <modulesummary>Heartbeat monitoring of an Erlang runtime system.</modulesummary> <description> <p>This modules contains the interface to the <c>heart</c> process. <c>heart</c> sends periodic heartbeats to an external port program, which is also named <c>heart</c>. The purpose of - the heart port program is to check that the Erlang runtime system + the <c>heart</c> port program is to check that the Erlang runtime system it is supervising is still running. If the port program has not received any heartbeats within <c>HEART_BEAT_TIMEOUT</c> seconds - (default is 60 seconds), the system can be rebooted. Also, if + (defaults to 60 seconds), the system can be rebooted. Also, if the system is equipped with a hardware watchdog timer and is running Solaris, the watchdog can be used to supervise the entire system.</p> - <p>An Erlang runtime system to be monitored by a heart program, - should be started with the command line flag <c>-heart</c> (see - also <seealso marker="erts:erl">erl(1)</seealso>). The <c>heart</c> - process is then started automatically:</p> + <p>An Erlang runtime system to be monitored by a heart program + is to be started with command-line flag <c>-heart</c> (see + also <seealso marker="erts:erl"><c>erl(1)</c></seealso>). + The <c>heart</c> process is then started automatically:</p> <pre> % <input>erl -heart ...</input></pre> - <p>If the system should be rebooted because of missing heart-beats, - or a terminated Erlang runtime system, the environment variable - <c>HEART_COMMAND</c> has to be set before the system is started. - If this variable is not set, a warning text will be printed but - the system will not reboot. However, if the hardware watchdog is - used, it will trigger a reboot <c>HEART_BEAT_BOOT_DELAY</c> - seconds later nevertheless (default is 60).</p> - <p>To reboot on the WINDOWS platform <c>HEART_COMMAND</c> can be + <p>If the system is to be rebooted because of missing heartbeats, + or a terminated Erlang runtime system, environment variable + <c>HEART_COMMAND</c> must be set before the system is started. + If this variable is not set, a warning text is printed but + the system does not reboot. However, if the hardware watchdog is + used, it still triggers a reboot <c>HEART_BEAT_BOOT_DELAY</c> + seconds later (defaults to 60 seconds).</p> + <p>To reboot on Windows, <c>HEART_COMMAND</c> can be set to <c>heart -shutdown</c> (included in the Erlang delivery) - or of course to any other suitable program which can activate a - reboot.</p> - <p>The hardware watchdog will not be started under Solaris if - the environment variable <c>HW_WD_DISABLE</c> is set.</p> - <p>The <c>HEART_BEAT_TIMEOUT</c> and <c>HEART_BEAT_BOOT_DELAY</c> - environment variables can be used to configure the heart timeouts, - they can be set in the operating system shell before Erlang is - started or be specified at the command line:</p> + or to any other suitable program that can activate a reboot.</p> + <p>The hardware watchdog is not started under Solaris if + environment variable <c>HW_WD_DISABLE</c> is set.</p> + <p>The environment variables <c>HEART_BEAT_TIMEOUT</c> and + <c>HEART_BEAT_BOOT_DELAY</c> can be used to configure the heart + time-outs; they can be set in the operating system shell before Erlang + is started or be specified at the command line:</p> <pre> % <input>erl -heart -env HEART_BEAT_TIMEOUT 30 ...</input></pre> <p>The value (in seconds) must be in the range 10 < X <= 65535.</p> - <p>It should be noted that if the system clock is adjusted with - more than <c>HEART_BEAT_TIMEOUT</c> seconds, <c>heart</c> will - timeout and try to reboot the system. This can happen, for - example, if the system clock is adjusted automatically by use of - NTP (Network Time Protocol).</p> - - <p> If a crash occurs, an <c><![CDATA[erl_crash.dump]]></c> will <em>not</em> be written - unless the environment variable <c><![CDATA[ERL_CRASH_DUMP_SECONDS]]></c> is set. - </p> - + <p>Notice that if the system clock is adjusted with + more than <c>HEART_BEAT_TIMEOUT</c> seconds, <c>heart</c> + times out and tries to reboot the system. This can occur, for + example, if the system clock is adjusted automatically by use of the + Network Time Protocol (NTP).</p> + <p>If a crash occurs, an <c><![CDATA[erl_crash.dump]]></c> is <em>not</em> + written unless environment variable + <c><![CDATA[ERL_CRASH_DUMP_SECONDS]]></c> is set:</p> <pre> % <input>erl -heart -env ERL_CRASH_DUMP_SECONDS 10 ...</input></pre> - - <p> If a regular core dump is wanted, let heart know by setting the kill signal to abort - using the environment variable <c><![CDATA[HEART_KILL_SIGNAL=SIGABRT]]></c>. - If unset, or not set to <c><![CDATA[SIGABRT]]></c>, the default behaviour will be a kill - signal using <c><![CDATA[SIGKILL]]></c>. - </p> - + <p>If a regular core dump is wanted, let <c>heart</c> know by setting + the kill signal to abort using environment variable + <c><![CDATA[HEART_KILL_SIGNAL=SIGABRT]]></c>. If unset, or not set to + <c><![CDATA[SIGABRT]]></c>, the default behavior is a kill signal using + <c><![CDATA[SIGKILL]]></c>:</p> <pre> % <input>erl -heart -env HEART_KILL_SIGNAL SIGABRT ...</input></pre> - - <p> - Furthermore, <c><![CDATA[ERL_CRASH_DUMP_SECONDS]]></c> has the following behaviour on - <c>heart</c>: - </p> - <taglist> - <tag><c><![CDATA[ERL_CRASH_DUMP_SECONDS=0]]></c></tag> - <item><p> - Suppresses the writing a crash dump file entirely, - thus rebooting the runtime system immediately. - This is the same as not setting the environment variable. - </p> - </item> - <tag><c><![CDATA[ERL_CRASH_DUMP_SECONDS=-1]]></c></tag> - <item><p> Setting the environment variable to a negative value will not reboot - the runtime system until the crash dump file has been completly written. - </p> - </item> - <tag><c><![CDATA[ERL_CRASH_DUMP_SECONDS=S]]></c></tag> - <item><p> - Heart will wait for <c>S</c> seconds to let the crash dump file be written. - After <c>S</c> seconds <c>heart</c> will reboot the runtime system regardless of - the crash dump file has been written or not. - </p> - </item> - </taglist> - - <p>In the following descriptions, all function fails with reason + <p>Furthermore, <c><![CDATA[ERL_CRASH_DUMP_SECONDS]]></c> has the + following behavior on <c>heart</c>:</p> + <taglist> + <tag><c><![CDATA[ERL_CRASH_DUMP_SECONDS=0]]></c></tag> + <item><p>Suppresses the writing of a crash dump file entirely, + thus rebooting the runtime system immediately. + This is the same as not setting the environment variable.</p> + </item> + <tag><c><![CDATA[ERL_CRASH_DUMP_SECONDS=-1]]></c></tag> + <item><p>Setting the environment variable to a negative value does not + reboot the runtime system until the crash dump file is completly + written.</p> + </item> + <tag><c><![CDATA[ERL_CRASH_DUMP_SECONDS=S]]></c></tag> + <item><p><c>heart</c> waits for <c>S</c> seconds to let the crash dump + file be written. After <c>S</c> seconds, <c>heart</c> reboots the + runtime system, whether the crash dump file is written or not.</p> + </item> + </taglist> + <p>In the following descriptions, all functions fail with reason <c>badarg</c> if <c>heart</c> is not started.</p> </description> @@ -128,37 +115,36 @@ <funcs> <func> <name name="set_cmd" arity="1"/> - <fsummary>Set a temporary reboot command</fsummary> + <fsummary>Set a temporary reboot command.</fsummary> <desc> - <p>Sets a temporary reboot command. This command is used if + <p>Sets a temporary reboot command. This command is used if a <c>HEART_COMMAND</c> other than the one specified with - the environment variable should be used in order to reboot - the system. The new Erlang runtime system will (if it - misbehaves) use the environment variable - <c>HEART_COMMAND</c> to reboot.</p> - - <p>Limitations: The <c><anno>Cmd</anno></c> command string - will be sent to the heart program as a ISO-latin-1 or UTF-8 - encoded binary depending on the file name encoding mode of the - emulator (see - <seealso marker="kernel:file#native_name_encoding/0"><c>file:native_name_encoding/0</c></seealso>). - The size of the encoded binary must be less than 2047 bytes.</p> + the environment variable is to be used to reboot + the system. The new Erlang runtime system uses (if it misbehaves) + environment variable <c>HEART_COMMAND</c> to reboot.</p> + <p>Limitations: Command string <c><anno>Cmd</anno></c> is sent to the + <c>heart</c> program as an ISO Latin-1 or UTF-8 encoded binary, + depending on the filename encoding mode of the emulator (see + <seealso marker="kernel:file#native_name_encoding/0"><c>file:native_name_encoding/0</c></seealso>). + The size of the encoded binary must be less than 2047 bytes.</p> </desc> </func> + <func> <name name="clear_cmd" arity="0"/> - <fsummary>Clear the temporary boot command</fsummary> + <fsummary>Clear the temporary boot command.</fsummary> <desc> <p>Clears the temporary boot command. If the system terminates, the normal <c>HEART_COMMAND</c> is used to reboot.</p> </desc> </func> + <func> <name name="get_cmd" arity="0"/> - <fsummary>Get the temporary reboot command</fsummary> + <fsummary>Get the temporary reboot command.</fsummary> <desc> - <p>Get the temporary reboot command. If the command is cleared, - the empty string will be returned.</p> + <p>Gets the temporary reboot command. If the command is cleared, + the empty string is returned.</p> </desc> </func> @@ -166,12 +152,12 @@ <name name="set_callback" arity="2"/> <fsummary>Set a validation callback</fsummary> <desc> - <p> This validation callback will be executed before any heartbeat sent - to the port program. For the validation to succeed it needs to return - with the value <c>ok</c>. + <p> This validation callback will be executed before any + heartbeat is sent to the port program. For the validation to + succeed it needs to return with the value <c>ok</c>. </p> - <p> An exception within the callback will be treated as a validation failure. </p> - <p> The callback will be removed if the system reboots. </p> + <p>An exception within the callback will be treated as a validation failure.</p> + <p>The callback will be removed if the system reboots.</p> </desc> </func> <func> diff --git a/lib/kernel/doc/src/inet.xml b/lib/kernel/doc/src/inet.xml index 088d78c1d6..cfff393b8c 100644 --- a/lib/kernel/doc/src/inet.xml +++ b/lib/kernel/doc/src/inet.xml @@ -29,43 +29,47 @@ <rev>A</rev> </header> <module>inet</module> - <modulesummary>Access to TCP/IP Protocols</modulesummary> + <modulesummary>Access to TCP/IP protocols.</modulesummary> <description> - <p>Provides access to TCP/IP protocols.</p> - <p>See also <em>ERTS User's Guide, Inet configuration</em> for more - information on how to configure an Erlang runtime system for IP - communication.</p> - <p>Two Kernel configuration parameters affect the behaviour of all - sockets opened on an Erlang node: - <c>inet_default_connect_options</c> can contain a list of default - options used for all sockets returned when doing <c>connect</c>, - and <c>inet_default_listen_options</c> can contain a list of - default options used when issuing a <c>listen</c> call. When - <c>accept</c> is issued, the values of the listensocket options - are inherited, why no such application variable is needed for + <p>This module provides access to TCP/IP protocols.</p> + <p>See also + <seealso marker="erts:inet_cfg">ERTS User's Guide: + Inet Configuration</seealso> for more information about how to + configure an Erlang runtime system for IP communication.</p> + <p>The following two <c>Kernel</c> configuration parameters affect the + behavior of all sockets opened on an Erlang node:</p> + <list type="bulleted"> + <item><p><c>inet_default_connect_options</c> can contain a list of + default options used for all sockets returned when doing + <c>connect</c>.</p></item> + <item><p><c>inet_default_listen_options</c> can contain a list of + default options used when issuing a <c>listen</c> call.</p></item> + </list> + <p>When <c>accept</c> is issued, the values of the listening socket options + are inherited. No such application variable is therefore needed for <c>accept</c>.</p> - <p>Using the Kernel configuration parameters mentioned above, one - can set default options for all TCP sockets on a node. This should - be used with care, but options like <c>{delay_send,true}</c> - might be specified in this way. An example of starting an Erlang - node with all sockets using delayed send could look like this:</p> + <p>Using the <c>Kernel</c> configuration parameters above, one + can set default options for all TCP sockets on a node, but use this + with care. Options such as <c>{delay_send,true}</c> can be + specified in this way. The following is an example of starting an Erlang + node with all sockets using delayed send:</p> <pre> $ <input>erl -sname test -kernel \</input> <input>inet_default_connect_options '[{delay_send,true}]' \</input> <input>inet_default_listen_options '[{delay_send,true}]'</input></pre> - <p>Note that the default option <c>{active, true}</c> currently + <p>Notice that default option <c>{active, true}</c> cannot be changed, for internal reasons.</p> <p>Addresses as inputs to functions can be either a string or a - tuple. For instance, the IP address 150.236.20.73 can be passed to - <c>gethostbyaddr/1</c> either as the string "150.236.20.73" - or as the tuple <c>{150, 236, 20, 73}</c>.</p> - <p>IPv4 address examples:</p> + tuple. For example, the IP address 150.236.20.73 can be passed to + <c>gethostbyaddr/1</c>, either as string <c>"150.236.20.73"</c> + or as tuple <c>{150, 236, 20, 73}</c>.</p> + <p><em>IPv4 address examples:</em></p> <code type="none"> Address ip_address() ------- ------------ 127.0.0.1 {127,0,0,1} 192.168.42.2 {192,168,42,2}</code> - <p>IPv6 address examples:</p> + <p><em>IPv6 address examples:</em></p> <code type="none"> Address ip_address() ------- ------------ @@ -77,7 +81,9 @@ FFFF::192.168.42.2 {16#3ffe,16#b80,16#1f8d,16#2,16#204,16#acff,16#fe17,16#bf38} fe80::204:acff:fe17:bf38 {16#fe80,0,0,0,0,16#204,16#acff,16#fe17,16#bf38}</code> - <p>A function that may be useful is <seealso marker="#parse_address/1">parse_address/1</seealso>:</p> + <p>Function + <seealso marker="#parse_address/1"><c>parse_address/1</c></seealso> + can be useful:</p> <pre> 1> <input>inet:parse_address("192.168.42.2").</input> {ok,{192,168,42,2}} @@ -89,9 +95,12 @@ fe80::204:acff:fe17:bf38 <datatype> <name name="hostent"/> <desc> - <p>The record is defined in the Kernel include file "inet.hrl". - Add the following directive to the module:</p> -<code>-include_lib("kernel/include/inet.hrl").</code></desc> + <p>The record is defined in the <c>Kernel</c> include file + <c>"inet.hrl"</c>.</p> + <p>Add the following directive to the module:</p> + <code> +-include_lib("kernel/include/inet.hrl").</code> + </desc> </datatype> <datatype> <name name="hostname"/> @@ -110,17 +119,20 @@ fe80::204:acff:fe17:bf38 </datatype> <datatype> <name name="posix"/> - <desc><p>An atom which is named from the Posix error codes - used in Unix, and in the runtime libraries of most - C compilers. See + <desc> + <p>An atom that is named from the POSIX error codes used in Unix, + and in the runtime libraries of most C compilers. See section <seealso marker="#error_codes">POSIX Error Codes</seealso>.</p> </desc> </datatype> <datatype> <name>socket()</name> - <desc><p><marker id="type-socket"></marker> - See <seealso marker="gen_tcp#type-socket">gen_tcp(3)</seealso> - and <seealso marker="gen_udp#type-socket">gen_udp(3)</seealso>.</p> + <desc> + <p><marker id="type-socket"></marker>See + <seealso marker="gen_tcp#type-socket"><c>gen_tcp:type-socket</c></seealso> + and + <seealso marker="gen_udp#type-socket"><c>gen_udp:type-socket</c></seealso>. + </p> </desc> </datatype> <datatype> @@ -131,443 +143,415 @@ fe80::204:acff:fe17:bf38 <funcs> <func> <name name="close" arity="1"/> - <fsummary>Close a socket of any type</fsummary> + <fsummary>Close a socket of any type.</fsummary> <desc> <p>Closes a socket of any type.</p> </desc> </func> + <func> - <name name="get_rc" arity="0"/> - <fsummary>Return a list of IP configuration parameters</fsummary> + <name name="format_error" arity="1"/> + <fsummary>Return a descriptive string for an error reason.</fsummary> <desc> - <p>Returns the state of the Inet configuration database in - form of a list of recorded configuration parameters. (See the - ERTS User's Guide, Inet configuration, for more information). - Only parameters with other than default values are returned.</p> + <p>Returns a diagnostic error string. For possible POSIX values and + corresponding strings, see section + <seealso marker="#error_codes">POSIX Error Codes</seealso>.</p> </desc> </func> + <func> - <name name="format_error" arity="1"/> - <fsummary>Return a descriptive string for an error reason</fsummary> + <name name="get_rc" arity="0"/> + <fsummary>Return a list of IP configuration parameters.</fsummary> <desc> - <p>Returns a diagnostic error string. See the section below - for possible Posix values and the corresponding - strings.</p> + <p>Returns the state of the <c>Inet</c> configuration database in + form of a list of recorded configuration parameters. For more + information, see <seealso marker="erts:inet_cfg">ERTS User's Guide: + Inet Configuration</seealso>. + Only parameters with other than default values are returned.</p> </desc> </func> + <func> <name name="getaddr" arity="2"/> - <fsummary>Return the IP-address for a host</fsummary> + <fsummary>Return the IP address for a host.</fsummary> <desc> - <p>Returns the IP-address for <c><anno>Host</anno></c> as a tuple of - integers. <c><anno>Host</anno></c> can be an IP-address, a single hostname - or a fully qualified hostname.</p> + <p>Returns the IP address for <c><anno>Host</anno></c> as a tuple of + integers. <c><anno>Host</anno></c> can be an IP address, a single + hostname, or a fully qualified hostname.</p> </desc> </func> + <func> <name name="getaddrs" arity="2"/> - <fsummary>Return the IP-addresses for a host</fsummary> + <fsummary>Return the IP addresses for a host.</fsummary> <desc> - <p>Returns a list of all IP-addresses for <c><anno>Host</anno></c>. - <c><anno>Host</anno></c> can be an IP-address, a single hostname or a fully - qualified hostname.</p> + <p>Returns a list of all IP addresses for <c><anno>Host</anno></c>. + <c><anno>Host</anno></c> can be an IP address, a single hostname, or + a fully qualified hostname.</p> </desc> </func> + <func> <name name="gethostbyaddr" arity="1"/> - <fsummary>Return a hostent record for the host with the given address</fsummary> + <fsummary>Return a hostent record for the host with the specified + address.</fsummary> <desc> - <p>Returns a <c>hostent</c> record given an address.</p> - </desc> + <p>Returns a <c>hostent</c> record for the host with the specified + address.</p></desc> </func> + <func> <name name="gethostbyname" arity="1"/> - <fsummary>Return a hostent record for the host with the given name</fsummary> + <fsummary>Return a hostent record for the host with the specified name. + </fsummary> <desc> - <p>Returns a <c>hostent</c> record given a hostname.</p> + <p>Returns a <c>hostent</c> record for the host with the specified + hostname.</p> </desc> </func> + <func> <name name="gethostbyname" arity="2"/> - <fsummary>Return a hostent record for the host with the given name</fsummary> + <fsummary>Return a hostent record for the host with the specified name. + </fsummary> <desc> - <p>Returns a <c>hostent</c> record given a hostname, restricted - to the given address family.</p> + <p>Returns a <c>hostent</c> record for the host with the specified + name, restricted to the specified address family.</p> </desc> </func> + <func> <name name="gethostname" arity="0"/> - <fsummary>Return the local hostname</fsummary> + <fsummary>Return the local hostname.</fsummary> <desc> - <p>Returns the local hostname. Will never fail.</p> + <p>Returns the local hostname. Never fails.</p> </desc> </func> <func> <name name="getifaddrs" arity="0"/> - <fsummary>Return a list of interfaces and their addresses</fsummary> - <desc> - <p> - Returns a list of 2-tuples containing interface names and the - interface's addresses. <c><anno>Ifname</anno></c> is a Unicode string. - <c><anno>Hwaddr</anno></c> is hardware dependent, e.g on Ethernet interfaces - it is the 6-byte Ethernet address (MAC address (EUI-48 address)). - </p> - <p> - The <c>{addr,<anno>Addr</anno>}</c>, <c>{netmask,_}</c> and <c>{broadaddr,_}</c> - tuples are repeated in the result list iff the interface has multiple - addresses. If you come across an interface that has - multiple <c>{flag,_}</c> or <c>{hwaddr,_}</c> tuples you have - a really strange interface or possibly a bug in this function. - The <c>{flag,_}</c> tuple is mandatory, all other optional. - </p> - <p> - Do not rely too much on the order of <c><anno>Flag</anno></c> atoms or - <c><anno>Ifopt</anno></c> tuples. There are some rules, though:</p> - <list> - <item> - Immediately after <c>{addr,_}</c> follows <c>{netmask,_}</c> - </item> - <item> - Immediately thereafter follows <c>{broadaddr,_}</c> if - the <c>broadcast</c> flag is <em>not</em> set and the - <c>pointtopoint</c> flag <em>is</em> set. - </item> - <item> - Any <c>{netmask,_}</c>, <c>{broadaddr,_}</c> or - <c>{dstaddr,_}</c> tuples that follow an <c>{addr,_}</c> - tuple concerns that address. - </item> - </list> - <p> - The <c>{hwaddr,_}</c> tuple is not returned on Solaris since the - hardware address historically belongs to the link layer and only - the superuser can read such addresses. - </p> - <p> - On Windows, the data is fetched from quite different OS API - functions, so the <c><anno>Netmask</anno></c> and <c><anno>Broadaddr</anno></c> - values may be calculated, just as some <c><anno>Flag</anno></c> values. - You have been warned. Report flagrant bugs. - </p> - </desc> + <fsummary>Return a list of interfaces and their addresses.</fsummary> + <desc> + <p>Returns a list of 2-tuples containing interface names and the + interface addresses. <c><anno>Ifname</anno></c> is a Unicode string. + <c><anno>Hwaddr</anno></c> is hardware dependent, for example, on + Ethernet interfaces + it is the 6-byte Ethernet address (MAC address (EUI-48 address)).</p> + <p>The tuples <c>{addr,<anno>Addr</anno>}</c>, <c>{netmask,_}</c>, and + <c>{broadaddr,_}</c> are repeated in the result list if the interface + has multiple addresses. If you come across an interface with + multiple <c>{flag,_}</c> or <c>{hwaddr,_}</c> tuples, you have + a strange interface or possibly a bug in this function. The tuple + <c>{flag,_}</c> is mandatory, all others are optional.</p> + <p>Do not rely too much on the order of <c><anno>Flag</anno></c> atoms + or <c><anno>Ifopt</anno></c> tuples. There are however some rules:</p> + <list type="bulleted"> + <item><p>Immediately after + <c>{addr,_}</c> follows <c>{netmask,_}</c>.</p></item> + <item><p>Immediately thereafter follows <c>{broadaddr,_}</c> if flag + <c>broadcast</c> is <em>not</em> set and flag + <c>pointtopoint</c> <em>is</em> set.</p></item> + <item><p>Any <c>{netmask,_}</c>, <c>{broadaddr,_}</c>, or + <c>{dstaddr,_}</c> tuples that follow an <c>{addr,_}</c> + tuple concerns that address.</p></item> + </list> + <p>The tuple <c>{hwaddr,_}</c> is not returned on Solaris, as the + hardware address historically belongs to the link layer and only + the superuser can read such addresses.</p> + <warning> + <p>On Windows, the data is fetched from different OS API functions, + so the <c><anno>Netmask</anno></c> and <c><anno>Broadaddr</anno></c> + values can be calculated, just as some <c><anno>Flag</anno></c> + values. Report flagrant bugs.</p> + </warning> + </desc> </func> <func> <name name="getopts" arity="2"/> - <fsummary>Get one or more options for a socket</fsummary> + <fsummary>Get one or more options for a socket.</fsummary> <type name="socket_getopt"/> <type name="socket_setopt"/> <desc> - <p>Gets one or more options for a socket. - See <seealso marker="#setopts/2">setopts/2</seealso> - for a list of available options.</p> - <p>The number of elements in the returned <c><anno>OptionValues</anno></c> + <p>Gets one or more options for a socket. For a list of available + options, see + <seealso marker="#setopts/2"><c>setopts/2</c></seealso>.</p> + <p>The number of elements in the returned + <c><anno>OptionValues</anno></c> list does not necessarily correspond to the number of options asked for. If the operating system fails to support an option, - it is simply left out in the returned list. An error tuple is only - returned when getting options for the socket is impossible - (i.e. the socket is closed or the buffer size in a raw request + it is left out in the returned list. An error tuple is returned + only when getting options for the socket is impossible (that is, + the socket is closed or the buffer size in a raw request is too large). This behavior is kept for backward compatibility reasons.</p> - <p>A raw option request <c>RawOptReq = {raw, Protocol, OptionNum, ValueSpec}</c> can be used to get information about + <p>A raw option request + <c>RawOptReq = {raw, Protocol, OptionNum, ValueSpec}</c> + can be used to get information about socket options not (explicitly) supported by the emulator. The - use of raw socket options makes the code non portable, but + use of raw socket options makes the code non-portable, but allows the Erlang programmer to take advantage of unusual features present on the current platform.</p> - <p>The <c>RawOptReq</c> consists of the tag <c>raw</c> followed - by the protocol level, the option number and either a binary + <p><c>RawOptReq</c> consists of tag <c>raw</c> followed + by the protocol level, the option number, and either a binary or the size, in bytes, of the - buffer in which the option value is to be stored. A binary - should be used when the underlying <c>getsockopt</c> requires - <em>input</em> - in the argument field, in which case the size of the binary - should correspond to the required buffer + buffer in which the option value is to be stored. A binary is to be + used when the underlying <c>getsockopt</c> requires <em>input</em> + in the argument field. In this case, the binary size + is to correspond to the required buffer size of the return value. The supplied values in a <c>RawOptReq</c> - correspond to the second, third and fourth/fifth parameters to the + correspond to the second, third, and fourth/fifth parameters to the <c>getsockopt</c> call in the C socket API. The value stored - in the buffer is returned as a binary <c>ValueBin</c> + in the buffer is returned as a binary <c>ValueBin</c>, where all values are coded in the native endianess.</p> - <p>Asking for and inspecting raw socket options require low - level information about the current operating system and TCP - stack.</p> - <p>As an example, consider a Linux machine where the - <c>TCP_INFO</c> option could be used to collect TCP statistics - for a socket. Lets say we're interested in the - <c>tcpi_sacked</c> field of the <c>struct tcp_info</c> - filled in when asking for <c>TCP_INFO</c>. To - be able to access this information, we need to know both the - numeric value of the protocol level <c>IPPROTO_TCP</c>, the - numeric value of the option <c>TCP_INFO</c>, the size of the - <c>struct tcp_info</c> and the size and offset of - the specific field. By inspecting the headers or writing a small C - program, we found <c>IPPROTO_TCP</c> to be 6, - <c>TCP_INFO</c> to be 11, the structure size to be 92 (bytes), - the offset of <c>tcpi_sacked</c> to be 28 bytes and the actual - value to be a 32 bit integer. We could use the following - code to retrieve the value:</p> + <p>Asking for and inspecting raw socket options require low-level + information about the current operating system and TCP stack.</p> + <p><em>Example:</em></p> + <p>Consider a Linux machine where option + <c>TCP_INFO</c> can be used to collect TCP statistics + for a socket. Assume you are interested in field + <c>tcpi_sacked</c> of <c>struct tcp_info</c> + filled in when asking for <c>TCP_INFO</c>. To be able to access + this information, you need to know the following:</p> + <list type="bulleted"> + <item>The numeric value of protocol level <c>IPPROTO_TCP</c></item> + <item>The numeric value of option <c>TCP_INFO</c></item> + <item>The size of <c>struct tcp_info</c></item> + <item>The size and offset of the specific field</item> + </list> + <p>By inspecting the headers or writing a small C program, it is found + that <c>IPPROTO_TCP</c> is 6, <c>TCP_INFO</c> is 11, the structure + size is 92 (bytes), the offset of <c>tcpi_sacked</c> is 28 bytes, + and the value is a 32-bit integer. The following code can be used + to retrieve the value:</p> <code type="none"><![CDATA[ - get_tcpi_sacked(Sock) -> - {ok,[{raw,_,_,Info}]} = inet:getopts(Sock,[{raw,6,11,92}]), - <<_:28/binary,TcpiSacked:32/native,_/binary>> = Info, - TcpiSacked.]]></code> - <p>Preferably, you would check the machine type, the OS - and the kernel version prior to executing anything similar to the - code above.</p> +get_tcpi_sacked(Sock) -> + {ok,[{raw,_,_,Info}]} = inet:getopts(Sock,[{raw,6,11,92}]), + <<_:28/binary,TcpiSacked:32/native,_/binary>> = Info, + TcpiSacked.]]></code> + <p>Preferably, you would check the machine type, the operating system, + and the <c>Kernel</c> version before executing anything similar to + this code.</p> </desc> </func> <func> <name name="getstat" arity="1"/> <name name="getstat" arity="2"/> - <fsummary>Get one or more statistic options for a socket</fsummary> + <fsummary>Get one or more statistic options for a socket.</fsummary> <type name="stat_option"/> <desc> <p>Gets one or more statistic options for a socket.</p> - - <p><c>getstat(<anno>Socket</anno>)</c> is equivalent to - <c>getstat(<anno>Socket</anno>, [recv_avg, recv_cnt, recv_dvi, - recv_max, recv_oct, send_avg, send_cnt, send_dvi, send_max, - send_oct])</c>.</p> - <p>The following options are available:</p> + <p><c>getstat(<anno>Socket</anno>)</c> is equivalent to + <c>getstat(<anno>Socket</anno>, [recv_avg, recv_cnt, recv_dvi, + recv_max, recv_oct, send_avg, send_cnt, send_dvi, send_max, + send_oct])</c>.</p> + <p>The following options are available:</p> <taglist> - <tag><c>recv_avg</c></tag> - <item> - <p>Average size of packets in bytes received by the socket.</p> - </item> - <tag><c>recv_cnt</c></tag> - <item> + <tag><c>recv_avg</c></tag> + <item> + <p>Average size of packets, in bytes, received by the socket.</p> + </item> + <tag><c>recv_cnt</c></tag> + <item> <p>Number of packets received by the socket.</p> - </item> - <tag><c>recv_dvi</c></tag> - <item> - <p>Average packet size deviation in bytes received by the socket.</p> - </item> - <tag><c>recv_max</c></tag> - <item> - <p>The size of the largest packet in bytes received by the socket.</p> - </item> - <tag><c>recv_oct</c></tag> - <item> + </item> + <tag><c>recv_dvi</c></tag> + <item> + <p>Average packet size deviation, in bytes, received by the socket.</p> + </item> + <tag><c>recv_max</c></tag> + <item> + <p>Size of the largest packet, in bytes, received by the socket.</p> + </item> + <tag><c>recv_oct</c></tag> + <item> <p>Number of bytes received by the socket.</p> - </item> - - <tag><c>send_avg</c></tag> - <item> - <p>Average size of packets in bytes sent from the socket.</p> - </item> - <tag><c>send_cnt</c></tag> - <item> + </item> + <tag><c>send_avg</c></tag> + <item> + <p>Average size of packets, in bytes, sent from the socket.</p> + </item> + <tag><c>send_cnt</c></tag> + <item> <p>Number of packets sent from the socket.</p> - </item> - <tag><c>send_dvi</c></tag> - <item> - <p>Average packet size deviation in bytes sent from the socket.</p> - </item> - <tag><c>send_max</c></tag> - <item> - <p>The size of the largest packet in bytes sent from the socket.</p> - </item> - <tag><c>send_oct</c></tag> - <item> + </item> + <tag><c>send_dvi</c></tag> + <item> + <p>Average packet size deviation, in bytes, sent from the socket.</p> + </item> + <tag><c>send_max</c></tag> + <item> + <p>Size of the largest packet, in bytes, sent from the socket.</p> + </item> + <tag><c>send_oct</c></tag> + <item> <p>Number of bytes sent from the socket.</p> - </item> + </item> </taglist> </desc> </func> + <func> <name name="ntoa" arity="1" /> - <fsummary>Convert IPv6 / IPV4 adress to ascii</fsummary> + <fsummary>Convert IPv6/IPV4 address to ASCII.</fsummary> + <desc> + <p>Parses an + <seealso marker="#type-ip_address"><c>ip_address()</c></seealso> + and returns an IPv4 or IPv6 address string.</p> + </desc> + </func> + + <func> + <name name="parse_address" arity="1" /> + <fsummary>Parse an IPv4 or IPv6 address.</fsummary> <desc> - <p>Parses an <seealso marker="#type-ip_address">ip_address()</seealso> and returns an IPv4 or IPv6 address string.</p> + <p>Parses an IPv4 or IPv6 address string and returns an + <seealso marker="#type-ip4_address"><c>ip4_address()</c></seealso> or + <seealso marker="#type-ip6_address"><c>ip6_address()</c></seealso>. + Accepts a shortened IPv4 address string.</p> </desc> </func> + <func> <name name="parse_ipv4_address" arity="1" /> - <fsummary>Parse an IPv4 address</fsummary> + <fsummary>Parse an IPv4 address.</fsummary> <desc> - <p>Parses an IPv4 address string and returns an <seealso marker="#type-ip4_address">ip4_address()</seealso>. - Accepts a shortened IPv4 shortened address string.</p> + <p>Parses an IPv4 address string and returns an + <seealso marker="#type-ip4_address"><c>ip4_address()</c></seealso>. + Accepts a shortened IPv4 address string.</p> </desc> </func> + <func> <name name="parse_ipv4strict_address" arity="1" /> <fsummary>Parse an IPv4 address strict.</fsummary> <desc> - <p>Parses an IPv4 address string containing four fields, i.e <em>not</em> shortened, and returns an <seealso marker="#type-ip4_address">ip4_address()</seealso>.</p> + <p>Parses an IPv4 address string containing four fields, that is, + <em>not</em> shortened, and returns an + <seealso marker="#type-ip4_address"><c>ip4_address()</c></seealso>. + </p> </desc> </func> + <func> <name name="parse_ipv6_address" arity="1" /> - <fsummary>Parse an IPv6 address</fsummary> + <fsummary>Parse an IPv6 address.</fsummary> <desc> - <p>Parses an IPv6 address string and returns an <seealso marker="#type-ip6_address">ip6_address()</seealso>. - If an IPv4 address string is passed, an IPv4-mapped IPv6 address is returned.</p> + <p>Parses an IPv6 address string and returns an + <seealso marker="#type-ip6_address"><c>ip6_address()</c></seealso>. + If an IPv4 address string is specified, an IPv4-mapped IPv6 address + is returned.</p> </desc> </func> + <func> <name name="parse_ipv6strict_address" arity="1" /> <fsummary>Parse an IPv6 address strict.</fsummary> <desc> - <p>Parses an IPv6 address string and returns an <seealso marker="#type-ip6_address">ip6_address()</seealso>. - Does <em>not</em> accept IPv4 adresses.</p> - </desc> - </func> - <func> - <name name="parse_address" arity="1" /> - <fsummary>Parse an IPv4 or IPv6 address.</fsummary> - <desc> - <p>Parses an IPv4 or IPv6 address string and returns an <seealso marker="#type-ip4_address">ip4_address()</seealso> or <seealso marker="#type-ip6_address">ip6_address()</seealso>. Accepts a shortened IPv4 address string.</p> + <p>Parses an IPv6 address string and returns an + <seealso marker="#type-ip6_address"><c>ip6_address()</c></seealso>. + Does <em>not</em> accept IPv4 addresses.</p> </desc> </func> + <func> <name name="parse_strict_address" arity="1" /> <fsummary>Parse an IPv4 or IPv6 address strict.</fsummary> <desc> - <p>Parses an IPv4 or IPv6 address string and returns an <seealso marker="#type-ip4_address">ip4_address()</seealso> or <seealso marker="#type-ip6_address">ip6_address()</seealso>. Does <em>not</em> accept a shortened IPv4 address string.</p> + <p>Parses an IPv4 or IPv6 address string and returns an + <seealso marker="#type-ip4_address"><c>ip4_address()</c></seealso> or + <seealso marker="#type-ip6_address"><c>ip6_address()</c></seealso>. + Does <em>not</em> accept a shortened IPv4 address string.</p> </desc> </func> + <func> <name name="peername" arity="1"/> - <fsummary>Return the address and port for the other end of a connection</fsummary> + <fsummary>Return the address and port for the other end of a connection. + </fsummary> <desc> - <p> - Returns the address and port for the other end of a - connection. - </p> - <p> - Note that for SCTP sockets this function only returns - one of the socket's peer addresses. The function - <seealso marker="#peernames/1">peernames/1,2</seealso> - returns all. - </p> + <p>Returns the address and port for the other end of a connection.</p> + <p>Notice that for SCTP sockets, this function returns only + one of the peer addresses of the socket. Function + <seealso marker="#peernames/1"><c>peernames/1,2</c></seealso> + returns all.</p> </desc> </func> + <func> <name name="peernames" arity="1"/> - <fsummary> - Return all address/port numbers for the other end of a connection - </fsummary> + <fsummary>Return all address/port numbers for the other end of a + connection.</fsummary> <desc> - <p> - Equivalent to + <p>Equivalent to <seealso marker="#peernames/2"><c>peernames(<anno>Socket</anno>, 0)</c></seealso>. - Note that this function's behaviour for an SCTP + </p> + <p>Notice that the behavior of this function for an SCTP one-to-many style socket is not defined by the - <url href="http://tools.ietf.org/html/draft-ietf-tsvwg-sctpsocket-13">SCTP Sockets API Extensions</url>. - </p> + <url href="http://tools.ietf.org/html/draft-ietf-tsvwg-sctpsocket-13">SCTP Sockets API Extensions</url>.</p> </desc> </func> + <func> <name name="peernames" arity="2"/> - <fsummary> - Return all address/port numbers for the other end of a connection - </fsummary> + <fsummary>Return all address/port numbers for the other end of a + connection.</fsummary> <desc> - <p> - Returns a list of all address/port number pairs for the other end - of a socket's association <c><anno>Assoc</anno></c>. - </p> - <p> - This function can return multiple addresses for multihomed - sockets such as SCTP sockets. For other sockets it - returns a one element list. - </p> - <p> - Note that the <c><anno>Assoc</anno></c> parameter is by the + <p>Returns a list of all address/port number pairs for the other end + of an association <c><anno>Assoc</anno></c> of a socket.</p> + <p>This function can return multiple addresses for multihomed + sockets, such as SCTP sockets. For other sockets it + returns a one-element list.</p> + <p>Notice that parameter <c><anno>Assoc</anno></c> is by the <url href="http://tools.ietf.org/html/draft-ietf-tsvwg-sctpsocket-13">SCTP Sockets API Extensions</url> defined to be ignored for - one-to-one style sockets. What the special value <c>0</c> - means hence its behaviour for one-to-many style sockets - is unfortunately not defined. - </p> + one-to-one style sockets. What the special value <c>0</c> + means, hence its behavior for one-to-many style sockets, + is unfortunately undefined.</p> </desc> </func> + <func> <name name="port" arity="1"/> - <fsummary>Return the local port number for a socket</fsummary> + <fsummary>Return the local port number for a socket.</fsummary> <desc> <p>Returns the local port number for a socket.</p> </desc> </func> - <func> - <name name="sockname" arity="1"/> - <fsummary>Return the local address and port number for a socket</fsummary> - <desc> - <p>Returns the local address and port number for a socket.</p> - <p> - Note that for SCTP sockets this function only returns - one of the socket addresses. The function - <seealso marker="#socknames/1">socknames/1,2</seealso> - returns all. - </p> - </desc> - </func> - <func> - <name name="socknames" arity="1"/> - <fsummary>Return all local address/port numbers for a socket</fsummary> - <desc> - <p> - Equivalent to - <seealso marker="#socknames/2"><c>socknames(<anno>Socket</anno>, 0)</c></seealso>. - </p> - </desc> - </func> - <func> - <name name="socknames" arity="2"/> - <fsummary>Return all local address/port numbers for a socket</fsummary> - <desc> - <p> - Returns a list of all local address/port number pairs for a socket - for the given association <c><anno>Assoc</anno></c>. - </p> - <p> - This function can return multiple addresses for multihomed - sockets such as SCTP sockets. For other sockets it - returns a one element list. - </p> - <p> - Note that the <c><anno>Assoc</anno></c> parameter is by the - <url href="http://tools.ietf.org/html/draft-ietf-tsvwg-sctpsocket-13">SCTP Sockets API Extensions</url> - defined to be ignored for one-to-one style sockets. - For one-to-many style sockets the special value <c>0</c> - is defined to mean that the returned addresses shall be - without regard to any particular association. - How different SCTP implementations interprets this varies somewhat. - </p> - </desc> - </func> + <func> <name name="setopts" arity="2"/> - <fsummary>Set one or more options for a socket</fsummary> + <fsummary>Set one or more options for a socket.</fsummary> <type name="socket_setopt"/> <desc> - <p>Sets one or more options for a socket. The following options - are available:</p> + <p>Sets one or more options for a socket.</p> + <p>The following options are available:</p> <taglist> <tag><c>{active, true | false | once | N}</c></tag> <item> <p>If the value is <c>true</c>, which is the default, - everything received from the socket will be sent as - messages to the receiving process. If the value is - <c>false</c> (passive mode), the process must explicitly - receive incoming data by calling + everything received from the socket is sent as + messages to the receiving process.</p> + <p>If the value is <c>false</c> (passive mode), the process must + explicitly receive incoming data by calling <seealso marker="gen_tcp#recv/2"><c>gen_tcp:recv/2,3</c></seealso>, - <seealso marker="gen_udp#recv/2"><c>gen_udp:recv/2,3</c></seealso> + <seealso marker="gen_udp#recv/2"><c>gen_udp:recv/2,3</c></seealso>, or <seealso marker="gen_sctp#recv/1"><c>gen_sctp:recv/1,2</c></seealso> (depending on the type of socket).</p> <p>If the value is <c>once</c> (<c>{active, once}</c>), - <em>one</em> data message from the socket will be sent - to the process. To receive one more message, - <c>setopts/2</c> must be called again with the - <c>{active, once}</c> option.</p> + <em>one</em> data message from the socket is sent + to the process. To receive one more message, + <c>setopts/2</c> must be called again with option + <c>{active, once}</c>.</p> <p>If the value is an integer <c>N</c> in the range -32768 to 32767 (inclusive), the value is added to the socket's count of data messages sent to the controlling process. A socket's default - message count is 0. If a negative value is specified and its - magnitude is equal to or greater than the socket's current - message count, the socket's message count is set to 0. Once - the socket's message count reaches 0, either due to sending + message count is <c>0</c>. If a negative value is specified, and + its magnitude is equal to or greater than the socket's current + message count, the socket's message count is set to <c>0</c>. + Once the socket's message count reaches <c>0</c>, either because + of sending received data messages to the process or by being explicitly set, the process is then notified by a special message, specific to the type of socket, that the socket has entered passive @@ -575,339 +559,298 @@ fe80::204:acff:fe17:bf38 messages <c>setopts/2</c> must be called again to set the socket back into an active mode.</p> <p>When using <c>{active, once}</c> or <c>{active, N}</c>, the - socket changes behaviour automatically when data is received. - This can sometimes be confusing in combination with - connection-oriented sockets (i.e. <c>gen_tcp</c>) as a socket - with <c>{active, false}</c> behaviour reports closing + socket changes behavior automatically when data is received. + This can be confusing in combination with connection-oriented + sockets (that is, <c>gen_tcp</c>), as a socket + with <c>{active, false}</c> behavior reports closing differently than a socket with <c>{active, true}</c> - behaviour. To make programming easier, a socket where - the peer closed and this was detected while in - <c>{active, false}</c> mode, will still generate the - message + behavior. To simplify programming, a socket where + the peer closed, and this is detected while in + <c>{active, false}</c> mode, still generates message <c>{tcp_closed,Socket}</c> when set to <c>{active, once}</c>, - <c>{active, true}</c> or <c>{active, N}</c> mode. It is therefore - safe to assume that the message - <c>{tcp_closed,Socket}</c>, possibly followed by socket - port termination (depending on the <c>exit_on_close</c> - option) will eventually appear when a socket changes + <c>{active, true}</c>, or <c>{active, N}</c> mode. + It is therefore safe to assume that message + <c>{tcp_closed,Socket}</c>, possibly followed by socket port + termination (depending on option <c>exit_on_close</c>) + eventually appears when a socket changes back and forth between <c>{active, true}</c> and <c>{active, false}</c> mode. However, - <em>when</em> peer closing is detected is all up to the + <em>when</em> peer closing is detected it is all up to the underlying TCP/IP stack and protocol.</p> - <p>Note that <c>{active, true}</c> mode provides no flow - control; a fast sender could easily overflow the - receiver with incoming messages. The same is true of - <c>{active, N}</c> mode while the message count is greater - than zero. Use active mode only if + <p>Notice that <c>{active, true}</c> mode provides no flow + control; a fast sender can easily overflow the + receiver with incoming messages. The same is true for + <c>{active, N}</c> mode, while the message count is greater + than zero.</p> + <p>Use active mode only if your high-level protocol provides its own flow control - (for instance, acknowledging received messages) or the + (for example, acknowledging received messages) or the amount of data exchanged is small. <c>{active, false}</c> - mode, use of the <c>{active, once}</c> mode or <c>{active, N}</c> + mode, use of the <c>{active, once}</c> mode, or <c>{active, N}</c> mode with values of <c>N</c> appropriate for the application - provides flow control; the other side will not be able send + provides flow control. The other side cannot send faster than the receiver can read.</p> </item> - - <tag><c>{broadcast, Boolean}</c>(UDP sockets)</tag> + <tag><c>{broadcast, Boolean}</c> (UDP sockets)</tag> <item> - <p>Enable/disable permission to send broadcasts.</p> - <marker id="option-buffer"></marker> + <p>Enables/disables permission to send broadcasts.</p> + <marker id="option-buffer"></marker> + </item> + <tag><c>{buffer, Size}</c></tag> + <item> + <p>The size of the user-level software buffer used by + the driver. Not to be confused with options <c>sndbuf</c> + and <c>recbuf</c>, which correspond to the + <c>Kernel</c> socket buffers. It is recommended + to have <c>val(buffer) >= max(val(sndbuf),val(recbuf))</c> to + avoid performance issues because of unnecessary copying. + <c>val(buffer)</c> is automatically set to the above + maximum when values <c>sndbuf</c> or <c>recbuf</c> are set. + However, as the sizes set for <c>sndbuf</c> and <c>recbuf</c> + usually become larger, you are encouraged to use + <seealso marker="#getopts/2"><c>getopts/2</c></seealso> + to analyze the behavior of your operating system.</p> </item> - - <tag><c>{buffer, Size}</c></tag> - <item> - <p>The size of the user-level software buffer used by - the driver. Not to be confused with <c>sndbuf</c> - and <c>recbuf</c> options which correspond to - the kernel socket buffers. It is recommended - to have <c>val(buffer) >= max(val(sndbuf),val(recbuf))</c> to - avoid performance issues due to unnecessary copying. - In fact, the <c>val(buffer)</c> is automatically set to - the above maximum when <c>sndbuf</c> or <c>recbuf</c> values are set. - However, since the actual sizes set for <c>sndbuf</c> and <c>recbuf</c> - usually becomes larger, you are encouraged to use - <seealso marker="inet#getopts/2"><c>inet:getopts/2</c></seealso> - to analyze the behavior of your operating system.</p> - </item> - <tag><c>{delay_send, Boolean}</c></tag> <item> <p>Normally, when an Erlang process sends to a socket, - the driver will try to immediately send the data. If that - fails, the driver will use any means available to queue + the driver tries to send the data immediately. If that + fails, the driver uses any means available to queue up the message to be sent whenever the operating system says it can handle it. Setting <c>{delay_send, true}</c> - will make <em>all</em> messages queue up. This makes - the messages actually sent onto the network be larger but - fewer. The option actually affects the scheduling of send + makes <em>all</em> messages queue up. The messages sent + to the network are then larger but fewer. + The option affects the scheduling of send requests versus Erlang processes instead of changing any - real property of the socket. Needless to say it is an - implementation specific option. Default is <c>false</c>.</p> + real property of the socket. The option is + implementation-specific. Defaults to <c>false</c>.</p> + </item> + <tag><c>{deliver, port | term}</c></tag> + <item> + <p>When <c>{active, true}</c>, data is delivered on the form + <c>port</c> : <c>{S, {data, [H1,..Hsz | Data]}}</c> or + <c>term</c> : <c>{tcp, S, [H1..Hsz | Data]}</c>.</p> </item> - - <tag><c>{deliver, port | term}</c></tag> - <item> <p> When <c>{active, true}</c> delivers data on the forms - <c>port</c> : <c>{S, {data, [H1,..Hsz | Data]}}</c> or - <c>term</c> : <c>{tcp, S, [H1..Hsz | Data]}</c>. - </p> - </item> - <tag><c>{dontroute, Boolean}</c></tag> <item> - <p>Enable/disable routing bypass for outgoing messages.</p> + <p>Enables/disables routing bypass for outgoing messages.</p> </item> - <tag><c>{exit_on_close, Boolean}</c></tag> <item> - <p>By default this option is set to <c>true</c>.</p> + <p>This option is set to <c>true</c> by default.</p> <p>The only reason to set it to <c>false</c> is if you want - to continue sending data to the socket after a close has - been detected, for instance if the peer has used - <seealso marker="gen_tcp#shutdown/2">gen_tcp:shutdown/2</seealso> - to shutdown the write side.</p> + to continue sending data to the socket after a close is + detected, for example, if the peer uses + <seealso marker="gen_tcp#shutdown/2"><c>gen_tcp:shutdown/2</c></seealso> + to shut down the write side.</p> </item> - <tag><c>{header, Size}</c></tag> <item> - <p>This option is only meaningful if the <c>binary</c> - option was specified when the socket was created. If - the <c>header</c> option is specified, the first + <p>This option is only meaningful if option <c>binary</c> + was specified when the socket was created. If option + <c>header</c> is specified, the first <c>Size</c> number bytes of data received from the socket - will be elements of a list, and the rest of the data will - be a binary given as the tail of the same list. If for - example <c>Size == 2</c>, the data received will match + are elements of a list, and the remaining data is + a binary specified as the tail of the same list. For example, + if <c>Size == 2</c>, the data received matches <c>[Byte1,Byte2|Binary]</c>.</p> </item> - <tag><c>{high_msgq_watermark, Size}</c></tag> <item> - <p>The socket message queue will be set into a busy - state when the amount of data queued on the message - queue reaches this limit. Note that this limit only - concerns data that have not yet reached the ERTS internal - socket implementation. Default value used is 8 kB.</p> - <p>Senders of data to the socket will be suspended if - either the socket message queue is busy, or the socket - itself is busy.</p> - <p>For more information see the <c>low_msgq_watermark</c>, - <c>high_watermark</c>, and <c>low_watermark</c> options.</p> - <p>Note that distribution sockets will disable the use of - <c>high_msgq_watermark</c> and <c>low_msgq_watermark</c>, - and will instead use the - <seealso marker="erts:erlang#system_info_dist_buf_busy_limit">distribution - buffer busy limit</seealso> which is a similar feature.</p> + <p>The socket message queue is set to a busy + state when the amount of data on the message + queue reaches this limit. Notice that this limit only + concerns data that has not yet reached the <c>ERTS</c> internal + socket implementation. Defaults to 8 kB.</p> + <p>Senders of data to the socket are suspended if + either the socket message queue is busy or the socket + itself is busy.</p> + <p>For more information, see options <c>low_msgq_watermark</c>, + <c>high_watermark</c>, and <c>low_watermark</c>.</p> + <p>Notice that distribution sockets disable the use of + <c>high_msgq_watermark</c> and <c>low_msgq_watermark</c>. + Instead use the + <seealso marker="erts:erlang#system_info_dist_buf_busy_limit">distribution buffer busy limit</seealso>, + which is a similar feature.</p> </item> - <tag><c>{high_watermark, Size}</c> (TCP/IP sockets)</tag> <item> - <p>The socket will be set into a busy state when the amount - of data queued internally by the ERTS socket implementation - reaches this limit. Default value used is 8 kB.</p> - <p>Senders of data to the socket will be suspended if - either the socket message queue is busy, or the socket - itself is busy.</p> - <p>For more information see the <c>low_watermark</c>, - <c>high_msgq_watermark</c>, and <c>low_msqg_watermark</c> - options.</p> + <p>The socket is set to a busy state when the amount + of data queued internally by the <c>ERTS</c> socket implementation + reaches this limit. Defaults to 8 kB.</p> + <p>Senders of data to the socket are suspended if + either the socket message queue is busy or the socket + itself is busy.</p> + <p>For more information, see options <c>low_watermark</c>, + <c>high_msgq_watermark</c>, and <c>low_msqg_watermark</c>.</p> </item> - <tag><c>{ipv6_v6only, Boolean}</c></tag> <item> - <p> - Restricts the socket to only use IPv6, prohibiting any + <p>Restricts the socket to use only IPv6, prohibiting any IPv4 connections. This is only applicable for - IPv6 sockets (option <c>inet6</c>). - </p> - <p> - On most platforms this option has to be set on the socket - before associating it to an address. Therefore it is only - reasonable to give it when creating the socket and not - to use it when calling the function - (<seealso marker="#setopts/2">setopts/2</seealso>) - containing this description. - </p> - <p> - The behaviour of a socket with this socket option set to - <c>true</c> is becoming the only portable one. The original + IPv6 sockets (option <c>inet6</c>).</p> + <p>On most platforms this option must be set on the socket + before associating it to an address. It is therefore only + reasonable to specify it when creating the socket and not + to use it when calling function + (<seealso marker="#setopts/2"><c>setopts/2</c></seealso>) + containing this description.</p> + <p>The behavior of a socket with this option set to + <c>true</c> is the only portable one. The original idea when IPv6 was new of using IPv6 for all traffic is now not recommended by FreeBSD (you can use <c>{ipv6_v6only,false}</c> to override the recommended system default value), - forbidden by OpenBSD (the supported GENERIC kernel) - and impossible on Windows (that has separate + forbidden by OpenBSD (the supported GENERIC kernel), + and impossible on Windows (which has separate IPv4 and IPv6 protocol stacks). Most Linux distros still have a system default value of <c>false</c>. - This policy shift among operating systems towards - separating IPv6 from IPv4 traffic has evolved since + This policy shift among operating systems to + separate IPv6 from IPv4 traffic has evolved, as it gradually proved hard and complicated to get - a dual stack implementation correct and secure. - </p> - <p> - On some platforms the only allowed value for this option - is <c>true</c>, e.g. OpenBSD and Windows. Trying to set - this option to <c>false</c> when creating the socket - will in this case fail. - </p> - <p> - Setting this option on platforms where it does not exist - is ignored and getting this option with - <seealso marker="#getopts/2">getopts/2</seealso> - returns no value i.e the returned list will not contain an - <c>{ipv6_v6only,_}</c> tuple. On Windows the option acually - does not exist, but it is emulated as being a - read-only option with the value <c>true</c>. - </p> - <p> - So it boils down to that setting this option to <c>true</c> - when creating a socket will never fail except possibly - (at the time of this writing) on a platform where you + a dual stack implementation correct and secure.</p> + <p>On some platforms, the only allowed value for this option + is <c>true</c>, for example, OpenBSD and Windows. Trying to set + this option to <c>false</c>, when creating the socket, fails + in this case.</p> + <p>Setting this option on platforms where it does not exist + is ignored. Getting this option with + <seealso marker="#getopts/2"><c>getopts/2</c></seealso> + returns no value, that is, the returned list does not contain an + <c>{ipv6_v6only,_}</c> tuple. On Windows, the option + does not exist, but it is emulated as a + read-only option with value <c>true</c>.</p> + <p>Therefore, setting this option to <c>true</c> + when creating a socket never fails, except possibly on a + platform where you have customized the kernel to only allow <c>false</c>, - which might be doable (but weird) on e.g. OpenBSD. - </p> - <p> - If you read back the option value using - <seealso marker="#getopts/2">getopts/2</seealso> - and get no value the option does not exist in the host OS - and all bets are off regarding the behaviour of both - an IPv6 and an IPv4 socket listening on the same port - as well as for an IPv6 socket getting IPv4 traffic. - </p> + which can be doable (but awkward) on, for example, OpenBSD.</p> + <p>If you read back the option value using + <seealso marker="#getopts/2"><c>getopts/2</c></seealso> + and get no value, the option does not exist in the host + operating system. The behavior of both an IPv6 and an IPv4 + socket listening on the same port, and for an IPv6 socket + getting IPv4 traffic is then no longer predictable.</p> </item> - <tag><c>{keepalive, Boolean}</c>(TCP/IP sockets)</tag> <item> <p>Enables/disables periodic transmission on a connected - socket, when no other data is being exchanged. If + socket when no other data is exchanged. If the other end does not respond, the connection is - considered broken and an error message will be sent to - the controlling process. Default disabled.</p> - <marker id="option-linger"></marker> + considered broken and an error message is sent to + the controlling process. Defaults to <c>disabled</c>.</p> + <marker id="option-linger"></marker> + </item> + <tag><c>{linger, {true|false, Seconds}}</c></tag> + <item> + <p>Determines the time-out, in seconds, for flushing unsent data + in the <c>close/1</c> socket call. If the first component of + the value tuple is <c>false</c>, the second is ignored. This + means that <c>close/1</c> returns immediately, not waiting + for data to be flushed. Otherwise, the second component is + the flushing time-out, in seconds.</p> </item> - - <tag><c>{linger, {true|false, Seconds}}</c></tag> - <item> - <p>Determines the timeout in seconds for flushing unsent data in the - <c>close/1</c> socket call. If the 1st component of the value - tuple is <c>false</c>, the 2nd one is ignored, which means that - <c>close/1</c> returns immediately not waiting - for data to be flushed. Otherwise, the 2nd component is - the flushing time-out in seconds.</p> - </item> - <tag><c>{low_msgq_watermark, Size}</c></tag> <item> <p>If the socket message queue is in a busy state, the - socket message queue will be set in a not busy state when - the amount of data queued in the message queue falls - below this limit. Note that this limit only concerns data - that have not yet reached the ERTS internal socket - implementation. Default value used is 4 kB.</p> - <p>Senders that have been suspended due to either a - busy message queue or a busy socket, will be resumed - when neither the socket message queue, nor the socket - are busy.</p> - <p>For more information see the <c>high_msgq_watermark</c>, - <c>high_watermark</c>, and <c>low_watermark</c> options.</p> - <p>Note that distribution sockets will disable the use of - <c>high_msgq_watermark</c> and <c>low_msgq_watermark</c>, - and will instead use the - <seealso marker="erts:erlang#system_info_dist_buf_busy_limit">distribution - buffer busy limit</seealso> which is a similar feature.</p> + socket message queue is set in a not busy state when + the amount of data queued in the message queue falls + below this limit. Notice that this limit only concerns data + that has not yet reached the <c>ERTS</c> internal socket + implementation. Defaults to 4 kB.</p> + <p>Senders that are suspended because of either a + busy message queue or a busy socket are resumed + when the socket message queue and the socket + are not busy.</p> + <p>For more information, see options <c>high_msgq_watermark</c>, + <c>high_watermark</c>, and <c>low_watermark</c>.</p> + <p>Notice that distribution sockets disable the use of + <c>high_msgq_watermark</c> and <c>low_msgq_watermark</c>. + Instead they use the + <seealso marker="erts:erlang#system_info_dist_buf_busy_limit">distribution + buffer busy limit</seealso>, which is a similar feature.</p> </item> - <tag><c>{low_watermark, Size}</c> (TCP/IP sockets)</tag> <item> - <p>If the socket is in a busy state, the socket will - be set in a not busy state when the amount of data - queued internally by the ERTS socket implementation - falls below this limit. Default value used is 4 kB.</p> - <p>Senders that have been suspended due to either a - busy message queue or a busy socket, will be resumed - when neither the socket message queue, nor the socket - are busy.</p> - <p>For more information see the <c>high_watermark</c>, - <c>high_msgq_watermark</c>, and <c>low_msgq_watermark</c> - options.</p> + <p>If the socket is in a busy state, the socket is + set in a not busy state when the amount of data + queued internally by the <c>ERTS</c> socket implementation + falls below this limit. Defaults to 4 kB.</p> + <p>Senders that are suspended because of a + busy message queue or a busy socket are resumed + when the socket message queue and the socket are not busy.</p> + <p>For more information, see options <c>high_watermark</c>, + <c>high_msgq_watermark</c>, and <c>low_msgq_watermark</c>.</p> </item> - - <tag><c>{mode, Mode :: binary | list}</c></tag> + <tag><c>{mode, Mode :: binary | list}</c></tag> <item> - <p>Received <c>Packet</c> is delivered as defined by Mode.</p> - </item> - + <p>Received <c>Packet</c> is delivered as defined by <c>Mode</c>. + </p> + </item> <tag><c>{netns, Namespace :: file:filename_all()}</c></tag> <item> - <p>Set a network namespace for the socket. The <c>Namespace</c> - parameter is a filename defining the namespace for example - <c>"/var/run/netns/example"</c> typically created by the command - <c>ip netns add example</c>. This option must be used in a - function call that creates a socket i.e - <seealso marker="gen_tcp#connect/3"> - gen_tcp:connect/3,4</seealso>, - <seealso marker="gen_tcp#listen/2"> - gen_tcp:listen/2</seealso>, - <seealso marker="gen_udp#open/1"> - gen_udp:open/1,2</seealso> or - <seealso marker="gen_sctp#open/0"> - gen_sctp:open/0-2</seealso>. - </p> - <p>This option uses the Linux specific syscall - <c>setns()</c> such as in Linux kernel 3.0 or later - and therefore only exists when the runtime system - has been compiled for such an operating system. - </p> - <p> - The virtual machine also needs elevated privileges either - running as superuser or (for Linux) having the capability - <c>CAP_SYS_ADMIN</c> according to the documentation for setns(2). - However, during testing also <c>CAP_SYS_PTRACE</c> - and <c>CAP_DAC_READ_SEARCH</c> has proven to be necessary. - Example:</p><code> -setcap cap_sys_admin,cap_sys_ptrace,cap_dac_read_search+epi beam.smp -</code> - <p>Note also that the filesystem containing the virtual machine - executable (<c>beam.smp</c> in the example above) has to be local, - mounted without the <c>nosetuid</c> flag, - support extended attributes and that - the kernel has to support file capabilities. - All this runs out of the box on at least Ubuntu 12.04 LTS, - except that SCTP sockets appears to not support - network namespaces. - </p> - <p>The <c>Namespace</c> is a file name and is encoded - and decoded as discussed in - <seealso marker="file">file</seealso> - except that the emulator flag <c>+fnu</c> is ignored and - <seealso marker="#getopts/2">getopts/2</seealso> - for this option will return a binary for the filename - if the stored filename can not be decoded, - which should only happen if you set the option using a binary - that can not be decoded with the emulator's filename encoding: - <seealso marker="file#native_name_encoding/0"> - file:native_name_encoding/0</seealso>. - </p> - </item> - - <tag><c>list</c></tag> + <p>Sets a network namespace for the socket. Parameter + <c>Namespace</c> is a filename defining the namespace, for + example, <c>"/var/run/netns/example"</c>, typically created by + command <c>ip netns add example</c>. This option must be used in + a function call that creates a socket, that is, + <seealso marker="gen_tcp#connect/3"><c>gen_tcp:connect/3,4</c></seealso>, + <seealso marker="gen_tcp#listen/2"><c>gen_tcp:listen/2</c></seealso>, + <seealso marker="gen_udp#open/1"><c>gen_udp:open/1,2</c></seealso>, or + <seealso marker="gen_sctp#open/0"><c>gen_sctp:open/0,1,2</c></seealso>.</p> + <p>This option uses the Linux-specific syscall + <c>setns()</c>, such as in Linux kernel 3.0 or later, + and therefore only exists when the runtime system + is compiled for such an operating system.</p> + <p>The virtual machine also needs elevated privileges, either + running as superuser or (for Linux) having capability + <c>CAP_SYS_ADMIN</c> according to the documentation for + <c>setns(2)</c>. + However, during testing also <c>CAP_SYS_PTRACE</c> + and <c>CAP_DAC_READ_SEARCH</c> have proven to be necessary.</p> + <p><em>Example:</em></p> + <code> +setcap cap_sys_admin,cap_sys_ptrace,cap_dac_read_search+epi beam.smp</code> + <p>Notice that the filesystem containing the virtual machine + executable (<c>beam.smp</c> in the example) must be local, + mounted without flag <c>nosetuid</c>, + support extended attributes, and + the kernel must support file capabilities. + All this runs out of the box on at least Ubuntu 12.04 LTS, + except that SCTP sockets appear to not support + network namespaces.</p> + <p><c>Namespace</c> is a filename and is encoded + and decoded as discussed in module + <seealso marker="file">file</seealso>, with the + following exceptions:</p> + <list type="bulleted"> + <item><p>Emulator flag <c>+fnu</c> is ignored.</p></item> + <item><p><seealso marker="#getopts/2"><c>getopts/2</c></seealso> + for this option returns a binary for the filename if the stored + filename cannot be decoded. This is only to occur if you set the + option using a binary that cannot be decoded with the emulator's + filename encoding: + <seealso marker="file#native_name_encoding/0"><c>file:native_name_encoding/0</c></seealso>.</p></item> + </list> + </item> + <tag><c>list</c></tag> <item> - <p>Received <c>Packet</c> is delivered as a list.</p> - </item> - - <tag><c>binary</c></tag> + <p>Received <c>Packet</c> is delivered as a list.</p> + </item> + <tag><c>binary</c></tag> <item> - <p>Received <c>Packet</c> is delivered as a binary.</p> - </item> - + <p>Received <c>Packet</c> is delivered as a binary.</p> + </item> <tag><c>{nodelay, Boolean}</c>(TCP/IP sockets)</tag> <item> - <p>If <c>Boolean == true</c>, the <c>TCP_NODELAY</c> option - is turned on for the socket, which means that even small - amounts of data will be sent immediately.</p> + <p>If <c>Boolean == true</c>, option <c>TCP_NODELAY</c> + is turned on for the socket, which means that also small + amounts of data are sent immediately.</p> </item> <tag><c>{packet, PacketType}</c>(TCP/IP sockets)</tag> <item> <p>Defines the type of packets to use for a socket. - The following values are valid:</p> + Possible values:</p> <taglist> <tag><c>raw | 0</c></tag> <item> @@ -917,104 +860,99 @@ setcap cap_sys_admin,cap_sys_ptrace,cap_dac_read_search+epi beam.smp <item> <p>Packets consist of a header specifying the number of bytes in the packet, followed by that number of bytes. - The length of header can be one, two, or four bytes; + The header length can be one, two, or four bytes, and containing an unsigned integer in big-endian byte order. - Each send operation will generate the header, and the header - will be stripped off on each receive operation.</p> - <p>In current implementation the 4-byte header is limited to 2Gb.</p> + Each send operation generates the header, and the header + is stripped off on each receive operation.</p> + <p>The 4-byte header is limited to 2Gb.</p> </item> <tag><c>asn1 | cdr | sunrm | fcgi | tpkt | line</c></tag> <item> <p>These packet types only have effect on receiving. When sending a packet, it is the responsibility of the application to supply a correct header. On - receiving, however, there will be one message sent to + receiving, however, one message is sent to the controlling process for each complete packet received, and, similarly, each call to <c>gen_tcp:recv/2,3</c> returns one complete packet. The header is <em>not</em> stripped off.</p> - <p>The meanings of the packet types are as follows: - <br></br> -<c>asn1</c> - ASN.1 BER, - <br></br> -<c>sunrm</c> - Sun's RPC encoding, - <br></br> -<c>cdr</c> - CORBA (GIOP 1.1), - <br></br> -<c>fcgi</c> - Fast CGI, - <br></br> -<c>tpkt</c> - TPKT format [RFC1006], - <br></br> -<c>line</c> - Line mode, a packet is a line - terminated with newline, lines longer than - the receive buffer are truncated.</p> - </item> + <p>The meanings of the packet types are as follows:</p> + <list type="bulleted"> + <item><c>asn1</c> - ASN.1 BER</item> + <item><c>sunrm</c> - Sun's RPC encoding</item> + <item><c>cdr</c> - CORBA (GIOP 1.1)</item> + <item><c>fcgi</c> - Fast CGI</item> + <item><c>tpkt</c> - TPKT format [RFC1006]</item> + <item><c>line</c> - Line mode, a packet is a line-terminated + with newline, lines longer than the receive buffer are + truncated</item> + </list> + </item> <tag><c>http | http_bin</c></tag> <item> <p>The Hypertext Transfer Protocol. The packets are returned with the format according to <c>HttpPacket</c> - described in <seealso marker="erts:erlang#decode_packet/3"> - erlang:decode_packet/3</seealso>. A socket in passive - mode will return <c>{ok, HttpPacket}</c> from <c>gen_tcp:recv</c> - while an active socket will send messages like <c>{http, - Socket, HttpPacket}</c>.</p> + described in + <seealso marker="erts:erlang#decode_packet/3"> + <c>erlang:decode_packet/3</c></seealso> in <c>ERTS</c>. + A socket in passive + mode returns <c>{ok, HttpPacket}</c> from <c>gen_tcp:recv</c> + while an active socket sends messages like + <c>{http, Socket, HttpPacket}</c>.</p> </item> <tag><c>httph | httph_bin</c></tag> <item> - <p>These two types are often not needed as the socket will - automatically switch from <c>http</c>/<c>http_bin</c> to + <p>These two types are often not needed, as the socket + automatically switches from <c>http</c>/<c>http_bin</c> to <c>httph</c>/<c>httph_bin</c> internally after the first line - has been read. There might be occasions however when they are + is read. However, there can be occasions when they are useful, such as parsing trailers from chunked encoding.</p> </item> </taglist> </item> <tag><c>{packet_size, Integer}</c>(TCP/IP sockets)</tag> <item> - <p>Sets the max allowed length of the packet body. If + <p>Sets the maximum allowed length of the packet body. If the packet header indicates that the length of the packet - is longer than the max allowed length, the packet is - considered invalid. The same happens if the packet header - is too big for the socket receive buffer.</p> - <p>For line oriented protocols (<c>line</c>,<c>http*</c>), - option <c>packet_size</c> also guarantees that lines up to the - indicated length are accepted and not considered invalid due - to internal buffer limitations.</p> + is longer than the maximum allowed length, the packet is + considered invalid. The same occurs if the packet header + is too large for the socket receive buffer.</p> + <p>For line-oriented protocols (<c>line</c>, <c>http*</c>), + option <c>packet_size</c> also guarantees that lines up to the + indicated length are accepted and not considered invalid + because of internal buffer limitations.</p> </item> <tag><c>{line_delimiter, Char}</c>(TCP/IP sockets)</tag> <item> - <p>Sets the line delimiting character for line oriented protocols - (<c>line</c>). Default value is <c>$\n</c>.</p> + <p>Sets the line delimiting character for line-oriented protocols + (<c>line</c>). Defaults to <c>$\n</c>.</p> + </item> + <tag><c>{priority, Priority}</c></tag> + <item> + <p>Sets the protocol-defined priority for all packets to be sent + on this socket.</p> + </item> + <tag><c>{raw, Protocol, OptionNum, ValueBin}</c></tag> + <item> + <p>See below.</p> </item> - - <tag><c>{priority, Priority}</c></tag> - <item> <p>Set the protocol-defined priority for all packets to be sent - on this socket.</p> - </item> - - <tag><c>{raw, Protocol, OptionNum, ValueBin}</c></tag> - <item> <p>See below.</p> - </item> - <tag><c>{read_packets, Integer}</c>(UDP sockets)</tag> <item> - <p>Sets the max number of UDP packets to read without + <p>Sets the maximum number of UDP packets to read without intervention from the socket when data is available. When this many packets have been read and delivered to the destination process, new packets are not read until a new notification of available data has arrived. - The default is 5, and if this parameter is set too - high the system can become unresponsive due to + Defaults to <c>5</c>. If this parameter is set too + high, the system can become unresponsive because of UDP packet flooding.</p> </item> <tag><c>{recbuf, Size}</c></tag> <item> <p>The minimum size of the receive buffer to use for the socket. You are encouraged to use - <seealso marker="inet#getopts/2"><c>inet:getopts/2</c></seealso>, - to retrieve the actual size set by your operating system. - - </p> + <seealso marker="#getopts/2"><c>getopts/2</c></seealso> + to retrieve the size set by your operating system.</p> </item> <tag><c>{reuseaddr, Boolean}</c></tag> <item> @@ -1023,118 +961,160 @@ setcap cap_sys_admin,cap_sys_ptrace,cap_dac_read_search+epi beam.smp </item> <tag><c>{send_timeout, Integer}</c></tag> <item> - <p>Only allowed for connection oriented sockets.</p> + <p>Only allowed for connection-oriented sockets.</p> <p>Specifies a longest time to wait for a send operation to be accepted by the underlying TCP stack. When the limit is - exceeded, the send operation will return - <c>{error,timeout}</c>. How much of a packet that actually - got sent is unknown, why the socket should be closed - whenever a timeout has occurred (see <c>send_timeout_close</c>). - Default is <c>infinity</c>.</p> + exceeded, the send operation returns + <c>{error,timeout}</c>. How much of a packet that + got sent is unknown; the socket is therefore to be closed + whenever a time-out has occurred (see <c>send_timeout_close</c> + below). Defaults to <c>infinity</c>.</p> </item> <tag><c>{send_timeout_close, Boolean}</c></tag> <item> - <p>Only allowed for connection oriented sockets.</p> + <p>Only allowed for connection-oriented sockets.</p> <p>Used together with <c>send_timeout</c> to specify whether - the socket will be automatically closed when the send operation + the socket is to be automatically closed when the send operation returns <c>{error,timeout}</c>. The recommended setting is - <c>true</c> which will automatically close the socket. - Default is <c>false</c> due to backward compatibility.</p> - <marker id="option-sndbuf"></marker> + <c>true</c>, which automatically closes the socket. + Defaults to <c>false</c> because of backward compatibility.</p> + <marker id="option-sndbuf"></marker> </item> - <tag><c>{show_econnreset, Boolean}</c>(TCP/IP sockets)</tag> <item> - <p>When this option is set to <c>false</c>, as it is by - default, an RST that is received from the TCP peer is treated - as a normal close (as though a FIN was sent). A caller - to <seealso marker="gen_tcp#recv/2">gen_tcp:recv/2</seealso> - will get <c>{error, closed}</c>. In active - mode the controlling process will receive a + <p>When this option is set to <c>false</c>, which is + default, an RST received from the TCP peer is treated + as a normal close (as though an FIN was sent). A caller to + <seealso marker="gen_tcp#recv/2"><c>gen_tcp:recv/2</c></seealso> + gets <c>{error, closed}</c>. In active + mode, the controlling process receives a <c>{tcp_close, Socket}</c> message, indicating that the peer has closed the connection.</p> - <p>Setting this option to <c>true</c> will allow you to + <p>Setting this option to <c>true</c> allows you to distinguish between a connection that was closed normally, - and one which was aborted (intentionally or unintentionally) + and one that was aborted (intentionally or unintentionally) by the TCP peer. A call to - <seealso marker="gen_tcp#recv/2">gen_tcp:recv/2</seealso> - will return <c>{error, econnreset}</c>. In - active mode, the controlling process will receive a + <seealso marker="gen_tcp#recv/2"><c>gen_tcp:recv/2</c></seealso> + returns <c>{error, econnreset}</c>. In + active mode, the controlling process receives a <c>{tcp_error, Socket, econnreset}</c> message before the usual <c>{tcp_closed, Socket}</c>, as is the case for any other socket error. Calls to - <seealso marker="gen_tcp#send/2">gen_tcp:send/2</seealso> - will also return <c>{error, econnreset}</c> when it + <seealso marker="gen_tcp#send/2"><c>gen_tcp:send/2</c></seealso> + also returns <c>{error, econnreset}</c> when it is detected that a TCP peer has sent an RST.</p> <p>A connected socket returned from - <seealso marker="gen_tcp#accept/1">gen_tcp:accept/1</seealso> - will inherit the <c>show_econnreset</c> setting from the + <seealso marker="gen_tcp#accept/1"><c>gen_tcp:accept/1</c></seealso> + inherits the <c>show_econnreset</c> setting from the listening socket.</p> - <marker id="option-show_econnreset"></marker> + <marker id="option-show_econnreset"></marker> </item> - <tag><c>{sndbuf, Size}</c></tag> <item> <p>The minimum size of the send buffer to use for the socket. - You are encouraged to use - <seealso marker="inet#getopts/2"><c>inet:getopts/2</c></seealso>, - to retrieve the actual size set by your operating system. - </p> + You are encouraged to use + <seealso marker="#getopts/2"><c>getopts/2</c></seealso>, + to retrieve the size set by your operating system.</p> </item> <tag><c>{priority, Integer}</c></tag> <item> - <p>Sets the SO_PRIORITY socket level option on platforms where - this is implemented. The behaviour and allowed range varies on - different systems. The option is ignored on platforms where the - option is not implemented. Use with caution.</p> + <p>Sets the <c>SO_PRIORITY</c> socket level option on platforms + where this is implemented. The behavior and allowed range varies + between different systems. + The option is ignored on platforms where it + is not implemented. Use with caution.</p> </item> <tag><c>{tos, Integer}</c></tag> <item> - <p>Sets IP_TOS IP level options on platforms where this is - implemented. The behaviour and allowed range varies on different - systems. The option is ignored on platforms where the option is - not implemented. Use with caution.</p> + <p>Sets <c>IP_TOS IP</c> level options on platforms where this is + implemented. The behavior and allowed range varies between + different systems. + The option is ignored on platforms where it is not + implemented. Use with caution.</p> </item> </taglist> - - <p>In addition to the options mentioned above, <em>raw</em> + <p>In addition to these options, <em>raw</em> option specifications can be used. The raw options are - specified as a tuple of arity four, beginning with the tag - <c>raw</c>, followed by the protocol level, the option number - and the actual option value specified as a binary. This - corresponds to the second, third and fourth argument to the + specified as a tuple of arity four, beginning with tag + <c>raw</c>, followed by the protocol level, the option number, + and the option value specified as a binary. This + corresponds to the second, third, and fourth arguments to the <c>setsockopt</c> call in the C socket API. The option value - needs to be coded in the native endianess of the platform and, - if a structure is required, needs to follow the struct + must be coded in the native endianess of the platform and, + if a structure is required, must follow the structure alignment conventions on the specific platform.</p> - <p>Using raw socket options require detailed knowledge about + <p>Using raw socket options requires detailed knowledge about the current operating system and TCP stack.</p> - <p>As an example of the usage of raw options, consider a Linux - system where you want to set the <c>TCP_LINGER2</c> option on - the <c>IPPROTO_TCP</c> protocol level in the stack. You know + <p><em>Example:</em></p> + <p>This example concerns the use of raw options. Consider a Linux + system where you want to set option <c>TCP_LINGER2</c> on + protocol level <c>IPPROTO_TCP</c> in the stack. You know that on this particular system it defaults to 60 (seconds), - but you would like to lower it to 30 for a particular - socket. The <c>TCP_LINGER2</c> option is not explicitly - supported by inet, but you know that the protocol level - translates to the number 6, the option number to the number 8 - and the value is to be given as a 32 bit integer. You can use - this line of code to set the option for the socket named + but you want to lower it to 30 for a particular + socket. Option <c>TCP_LINGER2</c> is not explicitly + supported by <c>inet</c>, but you know that the protocol level + translates to number 6, the option number to number 8, + and the value is to be specified as a 32-bit integer. You can use + this code line to set the option for the socket named <c>Sock</c>:</p> <code type="none"><![CDATA[ - inet:setopts(Sock,[{raw,6,8,<<30:32/native>>}]),]]></code> +inet:setopts(Sock,[{raw,6,8,<<30:32/native>>}]),]]></code> <p>As many options are silently discarded by the stack if they - are given out of range, it could be a good idea to check that - a raw option really got accepted. This code places the value - in the variable TcpLinger2:</p> + are specified out of range; it can be a good idea to check that + a raw option is accepted. The following code places the value + in variable <c>TcpLinger2:</c></p> <code type="none"><![CDATA[ - {ok,[{raw,6,8,<<TcpLinger2:32/native>>}]}=inet:getopts(Sock,[{raw,6,8,4}]),]]></code> - <p>Code such as the examples above is inherently non portable, - even different versions of the same OS on the same platform - may respond differently to this kind of option +{ok,[{raw,6,8,<<TcpLinger2:32/native>>}]}=inet:getopts(Sock,[{raw,6,8,4}]),]]></code> + <p>Code such as these examples is inherently non-portable, + even different versions of the same OS on the same platform + can respond differently to this kind of option manipulation. Use with care.</p> - <p>Note that the default options for TCP/IP sockets can be - changed with the Kernel configuration parameters mentioned in - the beginning of this document.</p> + <p>Notice that the default options for TCP/IP sockets can be + changed with the <c>Kernel</c> configuration parameters mentioned in + the beginning of this manual page.</p> + </desc> + </func> + + <func> + <name name="sockname" arity="1"/> + <fsummary>Return the local address and port number for a socket. + </fsummary> + <desc> + <p>Returns the local address and port number for a socket.</p> + <p>Notice that for SCTP sockets this function returns only + one of the socket addresses. Function + <seealso marker="#socknames/1"><c>socknames/1,2</c></seealso> + returns all.</p> + </desc> + </func> + + <func> + <name name="socknames" arity="1"/> + <fsummary>Return all local address/port numbers for a socket.</fsummary> + <desc> + <p>Equivalent to + <seealso marker="#socknames/2"><c>socknames(<anno>Socket</anno>, 0)</c></seealso>. + </p> + </desc> + </func> + + <func> + <name name="socknames" arity="2"/> + <fsummary>Return all local address/port numbers for a socket.</fsummary> + <desc> + <p>Returns a list of all local address/port number pairs for a socket + for the specified association <c><anno>Assoc</anno></c>.</p> + <p>This function can return multiple addresses for multihomed + sockets, such as SCTP sockets. For other sockets it + returns a one-element list.</p> + <p>Notice that parameter <c><anno>Assoc</anno></c> is by the + <url href="http://tools.ietf.org/html/draft-ietf-tsvwg-sctpsocket-13">SCTP Sockets API Extensions</url> + defined to be ignored for one-to-one style sockets. + For one-to-many style sockets, the special value <c>0</c> + is defined to mean that the returned addresses must be + without any particular association. + How different SCTP implementations interprets this varies somewhat. + </p> </desc> </func> </funcs> @@ -1143,148 +1123,147 @@ setcap cap_sys_admin,cap_sys_ptrace,cap_dac_read_search+epi beam.smp <marker id="error_codes"></marker> <title>POSIX Error Codes</title> <list type="bulleted"> - <item><c>e2big</c> - argument list too long</item> - <item><c>eacces</c> - permission denied</item> - <item><c>eaddrinuse</c> - address already in use</item> - <item><c>eaddrnotavail</c> - cannot assign requested address</item> - <item><c>eadv</c> - advertise error</item> - <item><c>eafnosupport</c> - address family not supported by - protocol family</item> - <item><c>eagain</c> - resource temporarily unavailable</item> + <item><c>e2big</c> - Too long argument list</item> + <item><c>eacces</c> - Permission denied</item> + <item><c>eaddrinuse</c> - Address already in use</item> + <item><c>eaddrnotavail</c> - Cannot assign requested address</item> + <item><c>eadv</c> - Advertise error</item> + <item><c>eafnosupport</c> - Address family not supported by + protocol family</item> + <item><c>eagain</c> - Resource temporarily unavailable</item> <item><c>ealign</c> - EALIGN</item> - <item><c>ealready</c> - operation already in progress</item> - <item><c>ebade</c> - bad exchange descriptor</item> - <item><c>ebadf</c> - bad file number</item> - <item><c>ebadfd</c> - file descriptor in bad state</item> - <item><c>ebadmsg</c> - not a data message</item> - <item><c>ebadr</c> - bad request descriptor</item> - <item><c>ebadrpc</c> - RPC structure is bad</item> - <item><c>ebadrqc</c> - bad request code</item> - <item><c>ebadslt</c> - invalid slot</item> - <item><c>ebfont</c> - bad font file format</item> - <item><c>ebusy</c> - file busy</item> - <item><c>echild</c> - no children</item> - <item><c>echrng</c> - channel number out of range</item> - <item><c>ecomm</c> - communication error on send</item> - <item><c>econnaborted</c> - software caused connection abort</item> - <item><c>econnrefused</c> - connection refused</item> - <item><c>econnreset</c> - connection reset by peer</item> - <item><c>edeadlk</c> - resource deadlock avoided</item> - <item><c>edeadlock</c> - resource deadlock avoided</item> - <item><c>edestaddrreq</c> - destination address required</item> - <item><c>edirty</c> - mounting a dirty fs w/o force</item> - <item><c>edom</c> - math argument out of range</item> - <item><c>edotdot</c> - cross mount point</item> - <item><c>edquot</c> - disk quota exceeded</item> - <item><c>eduppkg</c> - duplicate package name</item> - <item><c>eexist</c> - file already exists</item> - <item><c>efault</c> - bad address in system call argument</item> - <item><c>efbig</c> - file too large</item> - <item><c>ehostdown</c> - host is down</item> - <item><c>ehostunreach</c> - host is unreachable</item> - <item><c>eidrm</c> - identifier removed</item> - <item><c>einit</c> - initialization error</item> - <item><c>einprogress</c> - operation now in progress</item> - <item><c>eintr</c> - interrupted system call</item> - <item><c>einval</c> - invalid argument</item> + <item><c>ealready</c> - Operation already in progress</item> + <item><c>ebade</c> - Bad exchange descriptor</item> + <item><c>ebadf</c> - Bad file number</item> + <item><c>ebadfd</c> - File descriptor in bad state</item> + <item><c>ebadmsg</c> - Not a data message</item> + <item><c>ebadr</c> - Bad request descriptor</item> + <item><c>ebadrpc</c> - Bad RPC structure</item> + <item><c>ebadrqc</c> - Bad request code</item> + <item><c>ebadslt</c> - Invalid slot</item> + <item><c>ebfont</c> - Bad font file format</item> + <item><c>ebusy</c> - File busy</item> + <item><c>echild</c> - No children</item> + <item><c>echrng</c> - Channel number out of range</item> + <item><c>ecomm</c> - Communication error on send</item> + <item><c>econnaborted</c> - Software caused connection abort</item> + <item><c>econnrefused</c> - Connection refused</item> + <item><c>econnreset</c> - Connection reset by peer</item> + <item><c>edeadlk</c> - Resource deadlock avoided</item> + <item><c>edeadlock</c> - Resource deadlock avoided</item> + <item><c>edestaddrreq</c> - Destination address required</item> + <item><c>edirty</c> - Mounting a dirty fs without force</item> + <item><c>edom</c> - Math argument out of range</item> + <item><c>edotdot</c> - Cross mount point</item> + <item><c>edquot</c> - Disk quota exceeded</item> + <item><c>eduppkg</c> - Duplicate package name</item> + <item><c>eexist</c> - File already exists</item> + <item><c>efault</c> - Bad address in system call argument</item> + <item><c>efbig</c> - File too large</item> + <item><c>ehostdown</c> - Host is down</item> + <item><c>ehostunreach</c> - Host is unreachable</item> + <item><c>eidrm</c> - Identifier removed</item> + <item><c>einit</c> - Initialization error</item> + <item><c>einprogress</c> - Operation now in progress</item> + <item><c>eintr</c> - Interrupted system call</item> + <item><c>einval</c> - Invalid argument</item> <item><c>eio</c> - I/O error</item> - <item><c>eisconn</c> - socket is already connected</item> - <item><c>eisdir</c> - illegal operation on a directory</item> - <item><c>eisnam</c> - is a named file</item> - <item><c>el2hlt</c> - level 2 halted</item> - <item><c>el2nsync</c> - level 2 not synchronized</item> - <item><c>el3hlt</c> - level 3 halted</item> - <item><c>el3rst</c> - level 3 reset</item> + <item><c>eisconn</c> - Socket is already connected</item> + <item><c>eisdir</c> - Illegal operation on a directory</item> + <item><c>eisnam</c> - Is a named file</item> + <item><c>el2hlt</c> - Level 2 halted</item> + <item><c>el2nsync</c> - Level 2 not synchronized</item> + <item><c>el3hlt</c> - Level 3 halted</item> + <item><c>el3rst</c> - Level 3 reset</item> <item><c>elbin</c> - ELBIN</item> - <item><c>elibacc</c> - cannot access a needed shared library</item> - <item><c>elibbad</c> - accessing a corrupted shared library</item> - <item><c>elibexec</c> - cannot exec a shared library directly</item> - <item><c>elibmax</c> - attempting to link in more shared - libraries than system limit</item> - <item><c>elibscn</c> - .lib section in a.out corrupted</item> - <item><c>elnrng</c> - link number out of range</item> - <item><c>eloop</c> - too many levels of symbolic links</item> - <item><c>emfile</c> - too many open files</item> - <item><c>emlink</c> - too many links</item> - <item><c>emsgsize</c> - message too long</item> - <item><c>emultihop</c> - multihop attempted</item> - <item><c>enametoolong</c> - file name too long</item> - <item><c>enavail</c> - not available</item> + <item><c>elibacc</c> - Cannot access a needed shared library</item> + <item><c>elibbad</c> - Accessing a corrupted shared library</item> + <item><c>elibexec</c> - Cannot exec a shared library directly</item> + <item><c>elibmax</c> - Attempting to link in more shared + libraries than system limit</item> + <item><c>elibscn</c> - <c>.lib</c> section in <c>a.out</c> + corrupted</item> + <item><c>elnrng</c> - Link number out of range</item> + <item><c>eloop</c> - Too many levels of symbolic links</item> + <item><c>emfile</c> - Too many open files</item> + <item><c>emlink</c> - Too many links</item> + <item><c>emsgsize</c> - Message too long</item> + <item><c>emultihop</c> - Multihop attempted</item> + <item><c>enametoolong</c> - Filename too long</item> + <item><c>enavail</c> - Unavailable</item> <item><c>enet</c> - ENET</item> - <item><c>enetdown</c> - network is down</item> - <item><c>enetreset</c> - network dropped connection on reset</item> - <item><c>enetunreach</c> - network is unreachable</item> - <item><c>enfile</c> - file table overflow</item> - <item><c>enoano</c> - anode table overflow</item> - <item><c>enobufs</c> - no buffer space available</item> - <item><c>enocsi</c> - no CSI structure available</item> - <item><c>enodata</c> - no data available</item> - <item><c>enodev</c> - no such device</item> - <item><c>enoent</c> - no such file or directory</item> - <item><c>enoexec</c> - exec format error</item> - <item><c>enolck</c> - no locks available</item> - <item><c>enolink</c> - link has be severed</item> - <item><c>enomem</c> - not enough memory</item> - <item><c>enomsg</c> - no message of desired type</item> - <item><c>enonet</c> - machine is not on the network</item> - <item><c>enopkg</c> - package not installed</item> - <item><c>enoprotoopt</c> - bad protocol option</item> - <item><c>enospc</c> - no space left on device</item> - <item><c>enosr</c> - out of stream resources or not a stream - device</item> - <item><c>enosym</c> - unresolved symbol name</item> - <item><c>enosys</c> - function not implemented</item> - <item><c>enotblk</c> - block device required</item> - <item><c>enotconn</c> - socket is not connected</item> - <item><c>enotdir</c> - not a directory</item> - <item><c>enotempty</c> - directory not empty</item> - <item><c>enotnam</c> - not a named file</item> - <item><c>enotsock</c> - socket operation on non-socket</item> - <item><c>enotsup</c> - operation not supported</item> - <item><c>enotty</c> - inappropriate device for ioctl</item> - <item><c>enotuniq</c> - name not unique on network</item> - <item><c>enxio</c> - no such device or address</item> - <item><c>eopnotsupp</c> - operation not supported on socket</item> - <item><c>eperm</c> - not owner</item> - <item><c>epfnosupport</c> - protocol family not supported</item> - <item><c>epipe</c> - broken pipe</item> - <item><c>eproclim</c> - too many processes</item> - <item><c>eprocunavail</c> - bad procedure for program</item> - <item><c>eprogmismatch</c> - program version wrong</item> - <item><c>eprogunavail</c> - RPC program not available</item> - <item><c>eproto</c> - protocol error</item> - <item><c>eprotonosupport</c> - protocol not supported</item> - <item><c>eprototype</c> - protocol wrong type for socket</item> - <item><c>erange</c> - math result unrepresentable</item> + <item><c>enetdown</c> - Network is down</item> + <item><c>enetreset</c> - Network dropped connection on reset</item> + <item><c>enetunreach</c> - Network is unreachable</item> + <item><c>enfile</c> - File table overflow</item> + <item><c>enoano</c> - Anode table overflow</item> + <item><c>enobufs</c> - No buffer space available</item> + <item><c>enocsi</c> - No CSI structure available</item> + <item><c>enodata</c> - No data available</item> + <item><c>enodev</c> - No such device</item> + <item><c>enoent</c> - No such file or directory</item> + <item><c>enoexec</c> - Exec format error</item> + <item><c>enolck</c> - No locks available</item> + <item><c>enolink</c> - Link has been severed</item> + <item><c>enomem</c> - Not enough memory</item> + <item><c>enomsg</c> - No message of desired type</item> + <item><c>enonet</c> - Machine is not on the network</item> + <item><c>enopkg</c> - Package not installed</item> + <item><c>enoprotoopt</c> - Bad protocol option</item> + <item><c>enospc</c> - No space left on device</item> + <item><c>enosr</c> - Out of stream resources or not a stream device</item> + <item><c>enosym</c> - Unresolved symbol name</item> + <item><c>enosys</c> - Function not implemented</item> + <item><c>enotblk</c> - Block device required</item> + <item><c>enotconn</c> - Socket is not connected</item> + <item><c>enotdir</c> - Not a directory</item> + <item><c>enotempty</c> - Directory not empty</item> + <item><c>enotnam</c> - Not a named file</item> + <item><c>enotsock</c> - Socket operation on non-socket</item> + <item><c>enotsup</c> - Operation not supported</item> + <item><c>enotty</c> - Inappropriate device for <c>ioctl</c></item> + <item><c>enotuniq</c> - Name not unique on network</item> + <item><c>enxio</c> - No such device or address</item> + <item><c>eopnotsupp</c> - Operation not supported on socket</item> + <item><c>eperm</c> - Not owner</item> + <item><c>epfnosupport</c> - Protocol family not supported</item> + <item><c>epipe</c> - Broken pipe</item> + <item><c>eproclim</c> - Too many processes</item> + <item><c>eprocunavail</c> - Bad procedure for program</item> + <item><c>eprogmismatch</c> - Wrong program version</item> + <item><c>eprogunavail</c> - RPC program unavailable</item> + <item><c>eproto</c> - Protocol error</item> + <item><c>eprotonosupport</c> - Protocol not supported</item> + <item><c>eprototype</c> - Wrong protocol type for socket</item> + <item><c>erange</c> - Math result unrepresentable</item> <item><c>erefused</c> - EREFUSED</item> - <item><c>eremchg</c> - remote address changed</item> - <item><c>eremdev</c> - remote device</item> - <item><c>eremote</c> - pathname hit remote file system</item> - <item><c>eremoteio</c> - remote i/o error</item> + <item><c>eremchg</c> - Remote address changed</item> + <item><c>eremdev</c> - Remote device</item> + <item><c>eremote</c> - Pathname hit remote filesystem</item> + <item><c>eremoteio</c> - Remote I/O error</item> <item><c>eremoterelease</c> - EREMOTERELEASE</item> - <item><c>erofs</c> - read-only file system</item> - <item><c>erpcmismatch</c> - RPC version is wrong</item> - <item><c>erremote</c> - object is remote</item> - <item><c>eshutdown</c> - cannot send after socket shutdown</item> - <item><c>esocktnosupport</c> - socket type not supported</item> - <item><c>espipe</c> - invalid seek</item> - <item><c>esrch</c> - no such process</item> - <item><c>esrmnt</c> - srmount error</item> - <item><c>estale</c> - stale remote file handle</item> + <item><c>erofs</c> - Read-only filesystem</item> + <item><c>erpcmismatch</c> - Wrong RPC version</item> + <item><c>erremote</c> - Object is remote</item> + <item><c>eshutdown</c> - Cannot send after socket shutdown</item> + <item><c>esocktnosupport</c> - Socket type not supported</item> + <item><c>espipe</c> - Invalid seek</item> + <item><c>esrch</c> - No such process</item> + <item><c>esrmnt</c> - Srmount error</item> + <item><c>estale</c> - Stale remote file handle</item> <item><c>esuccess</c> - Error 0</item> - <item><c>etime</c> - timer expired</item> - <item><c>etimedout</c> - connection timed out</item> - <item><c>etoomanyrefs</c> - too many references</item> - <item><c>etxtbsy</c> - text file or pseudo-device busy</item> - <item><c>euclean</c> - structure needs cleaning</item> - <item><c>eunatch</c> - protocol driver not attached</item> - <item><c>eusers</c> - too many users</item> - <item><c>eversion</c> - version mismatch</item> - <item><c>ewouldblock</c> - operation would block</item> - <item><c>exdev</c> - cross-domain link</item> - <item><c>exfull</c> - message tables full</item> - <item><c>nxdomain</c> - the hostname or domain name could not be - found</item> + <item><c>etime</c> - Timer expired</item> + <item><c>etimedout</c> - Connection timed out</item> + <item><c>etoomanyrefs</c> - Too many references</item> + <item><c>etxtbsy</c> - Text file or pseudo-device busy</item> + <item><c>euclean</c> - Structure needs cleaning</item> + <item><c>eunatch</c> - Protocol driver not attached</item> + <item><c>eusers</c> - Too many users</item> + <item><c>eversion</c> - Version mismatch</item> + <item><c>ewouldblock</c> - Operation would block</item> + <item><c>exdev</c> - Cross-domain link</item> + <item><c>exfull</c> - Message tables full</item> + <item><c>nxdomain</c> - Hostname or domain name cannot be found</item> </list> </section> </erlref> diff --git a/lib/kernel/doc/src/inet_res.xml b/lib/kernel/doc/src/inet_res.xml index 851a36aba9..4ada4203c0 100644 --- a/lib/kernel/doc/src/inet_res.xml +++ b/lib/kernel/doc/src/inet_res.xml @@ -11,7 +11,7 @@ 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 @@ -19,7 +19,7 @@ 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> <title>inet_res</title> @@ -29,52 +29,50 @@ <rev>A</rev> </header> <module>inet_res</module> - <modulesummary>A Rudimentary DNS Client</modulesummary> + <modulesummary>A rudimentary DNS client.</modulesummary> <description> - <p>Performs DNS name resolving towards recursive name servers</p> - <p>See also - <seealso marker="erts:inet_cfg"> - ERTS User's Guide: Inet configuration - </seealso> for more - information on how to configure an Erlang runtime system for IP - communication and how to enable this DNS client by defining - <c><![CDATA['dns']]></c> as a lookup method. It then acts - as a backend for the resolving functions in - <seealso marker="kernel:inet">inet</seealso>.</p> + <p>This module performs DNS name resolving to recursive name servers.</p> + <p>See also + <seealso marker="erts:inet_cfg">ERTS User's Guide: Inet Configuration</seealso> + for more information about how to configure an Erlang runtime system + for IP communication, and how to enable this DNS client by defining + <c><![CDATA['dns']]></c> as a lookup method. + The DNS client then acts as a backend for the resolving functions in + <seealso marker="kernel:inet"><c>inet</c></seealso>.</p> <p>This DNS client can resolve DNS records even if it is not used for normal name resolving in the node.</p> - <p>This is not a full-fledged resolver. It is just a - DNS client that relies on asking trusted recursive nameservers.</p> + <p>This is not a full-fledged resolver, only a + DNS client that relies on asking trusted recursive name servers.</p> </description> <section> <title>Name Resolving</title> <p>UDP queries are used unless resolver option <c>usevc</c> is <c>true</c>, which forces TCP queries. - If the query is to large for UDP, TCP is used instead. - For regular DNS queries 512 bytes is the size limit. - When EDNS is enabled (resolver option - <c>edns</c> is set to the EDNS version i.e <c>0</c> + If the query is too large for UDP, TCP is used instead. + For regular DNS queries, 512 bytes is the size limit.</p> + <p>When EDNS is enabled (resolver option + <c>edns</c> is set to the EDNS version (that is, <c>0</c> instead of <c>false</c>), resolver option - <c>udp_payload_size</c> sets the limit. If a nameserver - replies with the TC bit set (truncation), indicating + <c>udp_payload_size</c> sets the limit. If a name server + replies with the TC bit set (truncation), indicating that the answer is incomplete, the query is retried - to that nameserver using TCP. The resolver option + to that name server using TCP. Resolver option <c>udp_payload_size</c> also sets the advertised - size for the max allowed reply size, if EDNS is - enabled, otherwise the nameserver uses the limit - 512 byte. If the reply is larger it gets truncated, - forcing a TCP re-query.</p> - <p>For UDP queries, the resolver options <c>timeout</c> + size for the maximum allowed reply size, if EDNS is + enabled, otherwise the name server uses the limit + 512 bytes. If the reply is larger, it gets truncated, + forcing a TCP requery.</p> + <p>For UDP queries, resolver options <c>timeout</c> and <c>retry</c> control retransmission. - Each nameserver in the <c>nameservers</c> list is - tried with a timeout of <c>timeout</c> / <c>retry</c>. - Then all nameservers are tried again doubling the - timeout, for a total of <c>retry</c> times.</p> - <p>For queries that not use the <c>search</c> list, + Each name server in the <c>nameservers</c> list is + tried with a time-out of <c>timeout</c>/<c>retry</c>. + Then all name servers are tried again, doubling the + time-out, for a total of <c>retry</c> times.</p> + <p>For queries not using the <c>search</c> list, if the query to all <c>nameservers</c> results in - <c>{error,nxdomain}</c>or an empty answer, the same - query is tried for the <c>alt_nameservers</c>.</p> + <c>{error,nxdomain}</c> or an empty answer, the same + query is tried for <c>alt_nameservers</c>.</p> </section> <section> @@ -92,11 +90,13 @@ <name name="res_error"/> </datatype> </datatypes> + <section> <title>DNS Types</title> <p><marker id="dns_types"/> The following data types concern the DNS client:</p> </section> + <datatypes> <datatype> <name name="dns_name"/> @@ -112,10 +112,10 @@ <name name="dns_msg"/> <desc> <p>This is the start of a hiearchy of opaque data structures - that can be examined with access functions in inet_dns that - return lists of {Field,Value} tuples. The arity 2 functions - just return the value for a given field.</p> -<pre> + that can be examined with access functions in <c>inet_dns</c>, which + return lists of <c>{Field,Value}</c> tuples. The arity 2 functions + only return the value for a specified field.</p> + <pre> dns_msg() = DnsMsg inet_dns:msg(DnsMsg) -> [ {header, dns_header()} @@ -163,63 +163,55 @@ dns_rr() = DnsRr | {z, integer()} | {data, dns_data()} ] inet_dns:rr(DnsRr, Field) -> Value</pre> - -<p>There is an info function for the types above:</p> - -<pre> + <p>There is an information function for the types above:</p> + <pre> inet_dns:record_type(dns_msg()) -> msg; inet_dns:record_type(dns_header()) -> header; inet_dns:record_type(dns_query()) -> dns_query; inet_dns:record_type(dns_rr()) -> rr; inet_dns:record_type(_) -> undefined.</pre> - -<p>So; inet_dns:(inet_dns:record_type(X))(X) will convert -any of these data structures into a {Field,Value} list.</p> + <p>So, <c>inet_dns:(inet_dns:record_type(X))(X)</c> converts + any of these data structures into a <c>{Field,Value}</c> list.</p> </desc> </datatype> <datatype> <name name="dns_data"/> - <desc><p><c><anno>Regexp</anno></c> is a string with characters encoded in the - UTF-8 coding standard.</p> + <desc> + <p><c><anno>Regexp</anno></c> is a string with characters encoded + in the UTF-8 coding standard.</p> </desc> </datatype> </datatypes> - <funcs> - <func> <name name="getbyname" arity="2"/> <name name="getbyname" arity="3"/> - <fsummary>Resolve a DNS record of the given type for the given host - </fsummary> + <fsummary>Resolve a DNS record of the specified type for the specified + host.</fsummary> <desc> - <p>Resolve a DNS record of the given type for the given host, - of class <c>in</c>. On success returns a <c>hostent()</c> record with - <c>dns_data()</c> elements in the address list field. - </p><p> - This function uses the resolver option <c>search</c> that + <p>Resolves a DNS record of the specified type for the specified host, + of class <c>in</c>. Returns, on success, a <c>hostent()</c> record + with <c>dns_data()</c> elements in the address list field.</p> + <p>This function uses resolver option <c>search</c> that is a list of domain names. If the name to resolve contains no dots, it is prepended to each domain name in the search list, and they are tried in order. If the name contains dots, it is first tried as an absolute name - and if that fails the search list is used. If the name - has a trailing dot it is simply supposed to be - an absolute name and the search list is not used. - </p> + and if that fails, the search list is used. If the name + has a trailing dot, it is supposed to be + an absolute name and the search list is not used.</p> </desc> </func> <func> <name name="gethostbyaddr" arity="1"/> <name name="gethostbyaddr" arity="2"/> - <fsummary>Return a hostent record for the host with the given address - </fsummary> + <fsummary>Return a hostent record for the host with the specified + address.</fsummary> <desc> <p>Backend functions used by - <seealso marker="kernel:inet#gethostbyaddr/1"> - inet:gethostbyaddr/1 - </seealso>. + <seealso marker="kernel:inet#gethostbyaddr/1"><c>inet:gethostbyaddr/1</c></seealso>. </p> </desc> </func> @@ -228,22 +220,19 @@ any of these data structures into a {Field,Value} list.</p> <name name="gethostbyname" arity="1"/> <name name="gethostbyname" arity="2"/> <name name="gethostbyname" arity="3"/> - <fsummary>Return a hostent record for the host with the given name + <fsummary>Return a hostent record for the host with the specified name. </fsummary> <desc> <p>Backend functions used by - <seealso marker="kernel:inet#gethostbyname/1"> - inet:gethostbyname/1,2 - </seealso>. - </p><p> - This function uses the resolver option <c>search</c> just like - <seealso marker="#getbyname/2">getbyname/2,3</seealso>. - </p><p> - If the resolver option <c>inet6</c> is <c>true</c>, - an IPv6 address is looked up, and if that fails - the IPv4 address is looked up and returned on - IPv6 mapped IPv4 format. + <seealso marker="kernel:inet#gethostbyname/1"><c>inet:gethostbyname/1,2</c></seealso>. </p> + <p>This function uses resolver option <c>search</c> just like + <seealso marker="#getbyname/2"><c>getbyname/2,3</c></seealso>. + </p> + <p>If resolver option <c>inet6</c> is <c>true</c>, + an IPv6 address is looked up. If that fails, + the IPv4 address is looked up and returned on + IPv6-mapped IPv4 format.</p> </desc> </func> @@ -251,22 +240,21 @@ any of these data structures into a {Field,Value} list.</p> <name name="lookup" arity="3"/> <name name="lookup" arity="4"/> <name name="lookup" arity="5"/> - <fsummary>Resolve the DNS data for the record of the given type and class - for the given name - </fsummary> + <fsummary>Resolve the DNS data for the record of the specified type + and class for the specified name.</fsummary> <desc> - <p>Resolve the DNS data for the record of the given type and class - for the given name. On success filters out the answer records - with the correct <c><anno>Class</anno></c> and <c><anno>Type</anno></c> and returns - a list of their data fields. So a lookup for type <c>any</c> - will give an empty answer since the answer records have + <p>Resolves the DNS data for the record of the specified type and class + for the specified name. On success, filters out the answer records + with the correct <c><anno>Class</anno></c> and + <c><anno>Type</anno></c>, and returns + a list of their data fields. So, a lookup for type <c>any</c> + gives an empty answer, as the answer records have specific types that are not <c>any</c>. An empty answer - as well as a failed lookup returns an empty list. - </p><p> - Calls <seealso marker="#resolve/3">resolve/2..4</seealso> + or a failed lookup returns an empty list.</p> + <p>Calls + <seealso marker="#resolve/3"><c>resolve/*</c></seealso> with the same arguments and filters the result, so - <c><anno>Opts</anno></c> is explained there. - </p> + <c><anno>Opts</anno></c> is described for those functions.</p> </desc> </func> @@ -274,90 +262,77 @@ any of these data structures into a {Field,Value} list.</p> <name name="resolve" arity="3"/> <name name="resolve" arity="4"/> <name name="resolve" arity="5"/> - <fsummary>Resolve a DNS record of the given type and class - for the given name - </fsummary> + <fsummary>Resolve a DNS record of the specified type and class + for the specified name.</fsummary> <desc> - <p>Resolve a DNS record of the given type and class for the given name. - The returned <c>dns_msg()</c> can be examined using - access functions in <c>inet_db</c> as described - in <seealso marker="#dns_types">DNS Types</seealso>. - </p><p> - If <c><anno>Name</anno></c> is an <c>ip_address()</c>, the domain name - to query for is generated as the standard reverse - ".IN-ADDR.ARPA." name for an IPv4 address, or the - ".IP6.ARPA." name for an IPv6 address. - In this case you most probably want to use - <c><anno>Class</anno> = in</c> and <c><anno>Type</anno> = ptr</c> but it - is not done automatically. - </p><p> - <c><anno>Opts</anno></c> override the corresponding resolver options. - If the option <c>nameservers</c> is given, it is - also assumed that it is the complete list of nameserves, - so the resolver option <c>alt_nameserves</c> is ignored. - Of course, if that option is also given to this function, - it is used. - </p><p> - The <c>verbose</c> option (or rather <c>{verbose,true}</c>), + <p>Resolves a DNS record of the specified type and class for the + specified name. The returned <c>dns_msg()</c> can be examined using + access functions in <c>inet_db</c>, as described in section + in <seealso marker="#dns_types">DNS Types</seealso>.</p> + <p>If <c><anno>Name</anno></c> is an <c>ip_address()</c>, the domain + name to query for is generated as the standard reverse + <c>".IN-ADDR.ARPA."</c> name for an IPv4 address, or the + <c>".IP6.ARPA."</c> name for an IPv6 address. + In this case, you most probably want to use + <c><anno>Class</anno> = in</c> and <c><anno>Type</anno> = ptr</c>, + but it is not done automatically.</p> + <p><c><anno>Opts</anno></c> overrides the corresponding resolver + options. If option <c>nameservers</c> is specified, it is + assumed that it is the complete list of name serves, + so resolver option <c>alt_nameserves</c> is ignored. + However, if option <c>alt_nameserves</c> is also specified to this + function, it is used.</p> + <p>Option <c>verbose</c> (or rather <c>{verbose,true}</c>) causes diagnostics printout through - <seealso marker="stdlib:io#format/3">io:format/2</seealso> - of queries, replies retransmissions, etc, similar - to from utilities like <c>dig</c>, <c>nslookup</c> et.al. - </p><p> - If <c><anno>Opt</anno></c> is an arbitrary atom it is interpreted + <seealso marker="stdlib:io#format/3"><c>io:format/2</c></seealso> + of queries, replies retransmissions, and so on, similar + to from utilities, such as <c>dig</c> and <c>nslookup</c>.</p> + <p>If <c><anno>Opt</anno></c> is any atom, it is interpreted as <c>{<anno>Opt</anno>,true}</c> unless the atom string starts with - <c>"no"</c> making the interpretation <c>{<anno>Opt</anno>,false}</c>. - For example: <c>usevc</c> is an alias for <c>{usevc,true}</c>, - and <c>nousevc</c> an alias for <c>{usevc,false}</c>. - </p><p> - The <c>inet6</c> option currently has no effect on this function. - You probably want to use <c><anno>Type</anno> = a | aaaa</c> instead. - </p> + <c>"no"</c>, making the + interpretation <c>{<anno>Opt</anno>,false}</c>. + For example, <c>usevc</c> is an alias for <c>{usevc,true}</c> + and <c>nousevc</c> is an alias for <c>{usevc,false}</c>.</p> + <p>Option <c>inet6</c> has no effect on this function. You + probably want to use <c><anno>Type</anno> = a | aaaa</c> instead.</p> </desc> </func> - </funcs> - - <section> - <title>Examples</title> - <p>Access functions example: how - <seealso marker="#lookup/3">lookup/3</seealso> - could have been implemented using - <seealso marker="#resolve/3">resolve/3</seealso> - from outside the module. - </p><code type="none"> - example_lookup(Name, Class, Type) -> - case inet_res:resolve(Name, Class, Type) of - {ok,Msg} -> - [inet_dns:rr(RR, data) - || RR <- inet_dns:msg(Msg, anlist), - inet_dns:rr(RR, type) =:= Type, - inet_dns:rr(RR, class) =:= Class]; - {error,_} -> - [] - end.</code> + <title>Example</title> + <p>This access functions example shows how + <seealso marker="#lookup/3"><c>lookup/3</c></seealso> + can be implemented using + <seealso marker="#resolve/3"><c>resolve/3</c></seealso> + from outside the module:</p> + <code type="none"> +example_lookup(Name, Class, Type) -> + case inet_res:resolve(Name, Class, Type) of + {ok,Msg} -> + [inet_dns:rr(RR, data) + || RR <- inet_dns:msg(Msg, anlist), + inet_dns:rr(RR, type) =:= Type, + inet_dns:rr(RR, class) =:= Class]; + {error,_} -> + [] + end.</code> </section> - - <section> <title>Legacy Functions</title> - <p>These have been deprecated due to the annoying double - meaning of the nameservers/timeout argument, and - because they had no decent place for a resolver options list.</p> + <p>These are deprecated because the annoying double + meaning of the name servers/time-out argument, and + because they have no decent place for a resolver options list.</p> </section> <funcs> - <func> <name name="nslookup" arity="3"/> <name name="nslookup" arity="4" clause_i="1"/> <name name="nslookup" arity="4" clause_i="2"/> - <fsummary>Resolve a DNS record of the given type and class - for the given name - </fsummary> + <fsummary>Resolve a DNS record of the specified type and class for the + specified name.</fsummary> <type variable="Name"/> <type variable="Class"/> <type variable="Type"/> @@ -365,23 +340,20 @@ any of these data structures into a {Field,Value} list.</p> <type variable="Nameservers"/> <type variable="Reason"/> <desc> - <p>Resolve a DNS record of the given type and class for the given name. - </p> + <p>Resolves a DNS record of the specified type and class for the + specified name.</p> </desc> </func> <func> <name name="nnslookup" arity="4"/> <name name="nnslookup" arity="5"/> - <fsummary>Resolve a DNS record of the given type and class - for the given name - </fsummary> + <fsummary>Resolve a DNS record of the specified type and class + for the specified name.</fsummary> <desc> - <p>Resolve a DNS record of the given type and class for the given name. - </p> + <p>Resolves a DNS record of the specified type and class for the + specified name.</p> </desc> </func> - </funcs> - </erlref> diff --git a/lib/kernel/doc/src/init_stub.xml b/lib/kernel/doc/src/init_stub.xml index 0fdf541037..df89b174ca 100644 --- a/lib/kernel/doc/src/init_stub.xml +++ b/lib/kernel/doc/src/init_stub.xml @@ -31,13 +31,9 @@ <rev>A</rev> </header> <module>init</module> - <modulesummary>Coordination of System Startup</modulesummary> - <description><p> - - The module init is moved to the runtime system - application. Please see <seealso - marker="erts:init">init(3)</seealso> in the - erts reference manual instead. - - </p></description> + <modulesummary>Coordination of system startup.</modulesummary> + <description> + <p>This module is moved to the + <seealso marker="erts:init"><c>ERTS</c></seealso> application.</p> + </description> </erlref> diff --git a/lib/kernel/doc/src/kernel_app.xml b/lib/kernel/doc/src/kernel_app.xml index 956c57f7c1..9e6fb60bb7 100644 --- a/lib/kernel/doc/src/kernel_app.xml +++ b/lib/kernel/doc/src/kernel_app.xml @@ -4,7 +4,7 @@ <appref> <header> <copyright> - <year>1996</year><year>2015</year> + <year>1996</year><year>2016</year> <holder>Ericsson AB. All Rights Reserved.</holder> </copyright> <legalnotice> @@ -29,66 +29,59 @@ <rev></rev> </header> <app>kernel</app> - <appsummary>The Kernel Application</appsummary> + <appsummary>The Kernel application.</appsummary> <description> - <p>The Kernel application is the first application started. It is + <p>The <c>Kernel</c> application has all the code necessary to run + the Erlang runtime system: file servers, code servers, + and so on.</p> + <p>The <c>Kernel</c> application is the first application started. It is mandatory in the sense that the minimal system based on - Erlang/OTP consists of Kernel and STDLIB. The Kernel application - contains the following services:</p> + Erlang/OTP consists of <c>Kernel</c> and <c>STDLIB</c>. <c>Kernel</c> + contains the following functional areas:</p> <list type="bulleted"> - <item>application controller, see <seealso marker="application">application(3)</seealso></item> - <item><c>code</c></item> - <item><c>disk_log</c></item> - <item><c>dist_ac</c>, distributed application controller</item> - <item><c>erl_boot_server</c></item> - <item><c>erl_ddll</c></item> - <item><c>error_logger</c></item> - <item><c>error_logger_format_depth</c></item> - <item><c>file</c></item> - <item><c>global</c></item> - <item><c>global_group</c></item> - <item><c>heart</c></item> - <item><c>inet</c></item> - <item><c>net_kernel</c></item> - <item><c>os</c></item> - <item><c>pg2</c></item> - <item><c>rpc</c></item> - <item><c>seq_trace</c></item> - <item><c>user</c></item> + <item>Start, stop, supervision, configuration, and distribution of applications</item> + <item>Code loading</item> + <item>Logging</item> + <item>Error logging</item> + <item>Global name service</item> + <item>Supervision of Erlang/OTP</item> + <item>Communication with sockets</item> + <item>Operating system interface</item> </list> </description> <section> <title>Error Logger Event Handlers</title> <p>Two standard error logger event handlers are defined in - the Kernel application. These are described in - <seealso marker="error_logger">error_logger(3)</seealso>.</p> + the <c>Kernel</c> application. These are described in + <seealso marker="error_logger"><c>error_logger(3)</c></seealso>.</p> </section> <section> <title>Configuration</title> - <p>The following configuration parameters are defined for the Kernel - application. See <seealso marker="app">app(4)</seealso> for more - information about configuration parameters.</p> + <p>The following configuration parameters are defined for the <c>Kernel</c> + application. For more information about configuration parameters, + see file <seealso marker="app"><c>app(4)</c></seealso>.</p> <taglist> <tag><c>browser_cmd = string() | {M,F,A}</c></tag> <item> - <p>When pressing the Help button in a tool such as Debugger or - TV, the help text (an HTML file <c>File</c>) is by default - displayed in a Netscape browser which is required to be up and - running. This parameter can be used to change the command for + <p>When pressing the <em>Help</em> button in a tool such as Debugger, + the help text (an HTML file <c>File</c>) is by default + displayed in a Netscape browser, which is required to be + operational. This parameter can be used to change the command for how to display the help text if another browser than Netscape - is preferred, or another platform than Unix or Windows is + is preferred, or if another platform than Unix or Windows is used.</p> <p>If set to a string <c>Command</c>, the command - <c>"Command File"</c> will be evaluated using <c>os:cmd/1</c>.</p> - <p>If set to a module-function-args tuple <c>{M,F,A}</c>, - the call <c>apply(M,F,[File|A])</c> will be evaluated.</p> + <c>"Command File"</c> is evaluated using + <seealso marker="os#cmd/1"><c>os:cmd/1</c></seealso>.</p> + <p>If set to a module-function-args tuple, <c>{M,F,A}</c>, + the call <c>apply(M,F,[File|A])</c> is evaluated.</p> </item> <tag><c>distributed = [Distrib]</c></tag> <item> - <p>Specifies which applications are distributed and on which - nodes they may execute. In this parameter:</p> + <p>Specifies which applications that are distributed and on which + nodes they are allowed to execute. In this parameter:</p> <list type="bulleted"> <item><c>Distrib = {App,Nodes} | {App,Time,Nodes}</c></item> <item><c>App = atom()</c></item> @@ -96,25 +89,24 @@ <item><c>Nodes = [node() | {node(),...,node()}]</c></item> </list> <p>The parameter is described in - <seealso marker="application">application(3)</seealso>, function - <c>load/2</c>.</p> + <seealso marker="application#load/2"><c>application:load/2</c></seealso>.</p> </item> <tag><c>dist_auto_connect = Value</c></tag> <item> - <p>Specifies when nodes will be automatically connected. If + <p>Specifies when nodes are automatically connected. If this parameter is not specified, a node is always - automatically connected, e.g when a message is to be sent to + automatically connected, for example, when a message is to be sent to that node. <c>Value</c> is one of:</p> <taglist> <tag><c>never</c></tag> - <item>Connections are never automatically established, they + <item><p>Connections are never automatically established, they must be explicitly connected. See - <seealso marker="net_kernel">net_kernel(3)</seealso>.</item> + <seealso marker="net_kernel"><c>net_kernel(3)</c></seealso>.</p></item> <tag><c>once</c></tag> - <item>Connections will be established automatically, but only + <item><p>Connections are established automatically, but only once per node. If a node goes down, it must thereafter be explicitly connected. See - <seealso marker="net_kernel">net_kernel(3)</seealso>.</item> + <seealso marker="net_kernel"><c>net_kernel(3)</c></seealso>.</p></item> </taglist> </item> <tag><c>permissions = [Perm]</c></tag> @@ -127,25 +119,24 @@ <item><c>Bool = boolean()</c></item> </list> <p>Permissions are described in - <seealso marker="application">application(3)</seealso>, function - <c>permit/2</c>.</p> + <seealso marker="application#permit/2"><c>application:permit/2</c></seealso>.</p> </item> <tag><c>error_logger = Value</c></tag> <item> <p><c>Value</c> is one of:</p> <taglist> <tag><c>tty</c></tag> - <item>Installs the standard event handler which prints error - reports to <c>stdio</c>. This is the default option.</item> + <item><p>Installs the standard event handler, which prints error + reports to <c>stdio</c>. This is the default option.</p></item> <tag><c>{file, FileName}</c></tag> - <item>Installs the standard event handler which prints error - reports to the file <c>FileName</c>, where <c>FileName</c> - is a string.</item> + <item><p>Installs the standard event handler, which prints error + reports to file <c>FileName</c>, where <c>FileName</c> + is a string.</p></item> <tag><c>false</c></tag> <item> <p>No standard event handler is installed, but the initial, primitive event handler is kept, printing - raw event messages to tty.</p> + raw event messages to <c>tty</c>.</p> </item> <tag><c>silent</c></tag> <item> @@ -156,111 +147,110 @@ <tag><c>error_logger_format_depth = Depth</c></tag> <item> <marker id="error_logger_format_depth"></marker> - <p>This parameter can be used to limit the size of the + <p>Can be used to limit the size of the formatted output from the error logger event handlers.</p> - <note><p>This configuration parameter was introduced in OTP 18.1. - It is currently experimental. Based on user feedback it - may be changed or improved in future releases, for example + <note><p>This configuration parameter was introduced in OTP 18.1 + and is experimental. Based on user feedback, it + can be changed or improved in future releases, for example, to gain better control over how to limit the size of the - formatted output. We have no plans to entirely remove this - new feature, unless it turns out to be completely - useless. In OTP 19, the default may be changed to limit the - formatted output.</p></note> + formatted output. We have no plans to remove this + new feature entirely, unless it turns out to be + useless.</p></note> - <p><c>Depth</c> is a positive integer that is the maximum + <p><c>Depth</c> is a positive integer representing the maximum depth to which terms are printed by the error logger event - handlers included in OTP. Specifically, the two event handlers + handlers included in OTP. This + configuration parameter is used by the two event handlers defined by the <c>Kernel</c> application and the two event - handlers in the <c>SASL</c> application will use this - configuration parameter. (If you have implemented you own - error handlers, this configuration parameter will have no - effect on them.)</p> + handlers in the <c>SASL</c> application. + (If you have implemented your own error handlers, this configuration + parameter has no effect on them.)</p> - <p>The way <c>Depth</c> is used, is that format strings - string passed to the event handlers will be rewritten. - The "~p" and "~w" format controls will be replaced with - "~P" and "~W", respectively, and <c>Depth</c> will be - used as the depth parameter. See - <seealso marker="stdlib:io#format/2">io:format/2</seealso>.</p> + <p><c>Depth</c> is used as follows: Format strings + passed to the event handlers are rewritten. + The format controls <c>~p</c> and <c>~w</c> are replaced with + <c>~P</c> and <c>~W</c>, respectively, and <c>Depth</c> is + used as the depth parameter. For details, see + <seealso marker="stdlib:io#format/2"><c>io:format/2</c></seealso> + in <c>STDLIB</c>.</p> <note><p>A reasonable starting value for <c>Depth</c> is - <c>30</c>. You should test crashing various processes in your - application and examine the logs from the crashes, and then - either increase or decrease the value.</p></note> + <c>30</c>. We recommend to test crashing various processes in your + application, examine the logs from the crashes, and then + increase or decrease the value.</p></note> </item> <tag><c>global_groups = [GroupTuple]</c></tag> <item> + <marker id="global_groups"></marker> <p>Defines global groups, see - <seealso marker="global_group">global_group(3)</seealso>.</p> + <seealso marker="global_group"><c>global_group(3)</c></seealso>. + In this parameter:</p> <list type="bulleted"> - <item><c>GroupTuple = {GroupName, [Node]} | {GroupName, PublishType, [Node]}</c></item> - <item><c>GroupName = atom()</c></item> - <item><c>PublishType = normal | hidden</c></item> - <item><c>Node = node()</c></item> + <item><p><c>GroupTuple = {GroupName, [Node]} | {GroupName, PublishType, [Node]}</c></p></item> + <item><p><c>GroupName = atom()</c></p></item> + <item><p><c>PublishType = normal | hidden</c></p></item> + <item><p><c>Node = node()</c></p></item> </list> </item> <tag><c>inet_default_connect_options = [{Opt, Val}]</c></tag> <item> <p>Specifies default options for <c>connect</c> sockets, - see <seealso marker="inet">inet(3)</seealso>.</p> + see <seealso marker="inet"><c>inet(3)</c></seealso>.</p> </item> <tag><c>inet_default_listen_options = [{Opt, Val}]</c></tag> <item> <p>Specifies default options for <c>listen</c> (and - <c>accept</c>) sockets, see <seealso marker="inet">inet(3)</seealso>.</p> + <c>accept</c>) sockets, see <seealso marker="inet"><c>inet(3)</c></seealso>.</p> </item> <tag><c>{inet_dist_use_interface, ip_address()}</c></tag> <item> - <p>If the host of an Erlang node has several network interfaces, - this parameter specifies which one to listen on. See - <seealso marker="inet">inet(3)</seealso> for the type definition - of <c>ip_address()</c>.</p> + <p>If the host of an Erlang node has many network interfaces, + this parameter specifies which one to listen on. For the type definition + of <c>ip_address()</c>, + see <seealso marker="inet"><c>inet(3)</c></seealso>.</p> </item> - <tag><c>{inet_dist_listen_min, First}</c></tag> + <tag><c>{inet_dist_listen_min, First}</c> and <c>{inet_dist_listen_max, Last}</c></tag> <item> - <p>See below.</p> - </item> - <tag><c>{inet_dist_listen_max, Last}</c></tag> - <item> - <p>Define the <c>First..Last</c> port range for the listener + <p>Defines the <c>First..Last</c> port range for the listener socket of a distributed Erlang node.</p> </item> <tag><c>{inet_dist_listen_options, Opts}</c></tag> <item> - <p>Define a list of extra socket options to be used when opening the + <p>Defines a list of extra socket options to be used when opening the listening socket for a distributed Erlang node. - See <seealso marker="gen_tcp#listen/2">gen_tcp:listen/2</seealso></p> + See <seealso marker="gen_tcp#listen/2"><c>gen_tcp:listen/2</c></seealso>.</p> </item> <tag><c>{inet_dist_connect_options, Opts}</c></tag> <item> - <p>Define a list of extra socket options to be used when connecting to + <p>Defines a list of extra socket options to be used when connecting to other distributed Erlang nodes. - See <seealso marker="gen_tcp#connect/4">gen_tcp:connect/4</seealso></p> + See <seealso marker="gen_tcp#connect/4"><c>gen_tcp:connect/4</c></seealso>.</p> </item> <tag><c>inet_parse_error_log = silent</c></tag> <item> - <p>If this configuration parameter is set, no + <p>If set, no <c>error_logger</c> messages are generated when erroneous lines are found and skipped in the various Inet configuration files.</p> </item> <tag><c>inetrc = Filename</c></tag> <item> - <p>The name (string) of an Inet user configuration file. See - ERTS User's Guide, Inet configuration.</p> + <p>The name (string) of an Inet user configuration file. For details, + see section + <seealso marker="erts:inet_cfg"><c>Inet Configuration</c></seealso> + in the <c>ERTS</c> User's Guide.</p> </item> <tag><c>net_setuptime = SetupTime</c></tag> <item> <marker id="net_setuptime"></marker> <p><c>SetupTime</c> must be a positive integer or floating point - number, and will be interpreted as the maximally allowed time + number, and is interpreted as the maximum allowed time for each network operation during connection setup to another - Erlang node. The maximum allowed value is 120; if higher values - are given, 120 will be used. The default value if the variable - is not given, or if the value is incorrect (e.g. not a number), - is 7 seconds.</p> - <p>Note that this value does not limit the total connection + Erlang node. The maximum allowed value is <c>120</c>. If higher values + are specified, <c>120</c> is used. Default is 7 seconds if the variable + is not specified, or if the value is incorrect (for example, not a number).</p> + <p>Notice that this value does not limit the total connection setup time, but rather each individual network operation during the connection setup and handshake.</p> </item> @@ -268,45 +258,44 @@ <item> <marker id="net_ticktime"></marker> <p>Specifies the <c>net_kernel</c> tick time. <c>TickTime</c> - is given in seconds. Once every <c>TickTime/4</c> second, all - connected nodes are ticked (if anything else has been written - to a node) and if nothing has been received from another node - within the last four (4) tick times that node is considered - to be down. This ensures that nodes which are not responding, + is specified in seconds. Once every <c>TickTime/4</c> second, all + connected nodes are ticked (if anything else is written + to a node). If nothing is received from another node + within the last four tick times, that node is considered + to be down. This ensures that nodes that are not responding, for reasons such as hardware errors, are considered to be down.</p> <p>The time <c>T</c>, in which a node that is not responding is - detected, is calculated as: <c><![CDATA[MinT < T < MaxT]]></c> where:</p> + detected, is calculated as <c><![CDATA[MinT < T < MaxT]]></c>, where:</p> <code type="none"> MinT = TickTime - TickTime / 4 MaxT = TickTime + TickTime / 4</code> - <p><c>TickTime</c> is by default 60 (seconds). Thus, + <p><c>TickTime</c> defaults to <c>60</c> (seconds). Thus, <c><![CDATA[45 < T < 75]]></c> seconds.</p> - <p><em>Note:</em> All communicating nodes should have the same + <p>Notice that <em>all</em> communicating nodes are to have the <em>same</em> <c>TickTime</c> value specified.</p> - <p><em>Note:</em> Normally, a terminating node is detected - immediately.</p> + <p>Normally, a terminating node is detected immediately.</p> </item> <tag><c>shutdown_timeout = integer() | infinity</c></tag> <item> - <p>Specifies the time <c>application_controller</c> will wait + <p>Specifies the time <c>application_controller</c> waits for an application to terminate during node shutdown. If the - timer expires, <c>application_controller</c> will brutally - kill <c>application_master</c> of the hanging + timer expires, <c>application_controller</c> brutally + kills <c>application_master</c> of the hanging application. If this parameter is undefined, it defaults to <c>infinity</c>.</p> </item> <tag><c>sync_nodes_mandatory = [NodeName]</c></tag> <item> - <p>Specifies which other nodes <em>must</em> be alive in order + <p>Specifies which other nodes that <em>must</em> be alive for this node to start properly. If some node in the list - does not start within the specified time, this node will not + does not start within the specified time, this node does not start either. If this parameter is undefined, it defaults to - [].</p> + <c>[]</c>.</p> </item> <tag><c>sync_nodes_optional = [NodeName]</c></tag> <item> - <p>Specifies which other nodes <em>can</em> be alive in order + <p>Specifies which other nodes that <em>can</em> be alive for this node to start properly. If some node in this list does not start within the specified time, this node starts anyway. If this parameter is undefined, it defaults to @@ -314,66 +303,65 @@ MaxT = TickTime + TickTime / 4</code> </item> <tag><c>sync_nodes_timeout = integer() | infinity</c></tag> <item> - <p>Specifies the amount of time (in milliseconds) this node - will wait for the mandatory and optional nodes to start. If + <p>Specifies the time (in milliseconds) that this node + waits for the mandatory and optional nodes to start. If this parameter is undefined, no node synchronization is - performed. This option also makes sure that <c>global</c> is + performed. This option ensures that <c>global</c> is synchronized.</p> </item> <tag><c>start_dist_ac = true | false</c></tag> <item> <p>Starts the <c>dist_ac</c> server if the parameter is - <c>true</c>. This parameter should be set to <c>true</c> for - systems that use distributed applications.</p> - <p>The default value is <c>false</c>. If this parameter is - undefined, the server is started if the parameter + <c>true</c>. This parameter is to be set to <c>true</c> for + systems using distributed applications.</p> + <p>Defaults to <c>false</c>. If this parameter is + undefined, the server is started if parameter <c>distributed</c> is set.</p> </item> <tag><c>start_boot_server = true | false</c></tag> <item> <p>Starts the <c>boot_server</c> if the parameter is <c>true</c> - (see <seealso marker="erl_boot_server">erl_boot_server(3)</seealso>). - This parameter should be - set to <c>true</c> in an embedded system which uses this - service.</p> - <p>The default value is <c>false</c>.</p> + (see <seealso marker="erl_boot_server"><c>erl_boot_server(3)</c></seealso>). + This parameter is to be set to <c>true</c> in an embedded system + using this service.</p> + <p>Defaults to <c>false</c>.</p> </item> <tag><c>boot_server_slaves = [SlaveIP]</c></tag> <item> - <p>If the <c>start_boot_server</c> configuration parameter is + <p>If configuration parameter <c>start_boot_server</c> is <c>true</c>, this parameter can be used to initialize - <c>boot_server</c> with a list of slave IP addresses. - <c>SlaveIP = string() | atom | {integer(),integer(),integer(),integer()}</c></p> + <c>boot_server</c> with a list of slave IP addresses:</p> + <p> + <c>SlaveIP = string() | atom | {integer(),integer(),integer(),integer()}</c>,</p> <p>where <c><![CDATA[0 <= integer() <=255]]></c>.</p> - <p>Examples of <c>SlaveIP</c> in atom, string and tuple form - are: <br></br> -<c>'150.236.16.70', "150,236,16,70", {150,236,16,70}</c>.</p> - <p>The default value is <c>[]</c>.</p> + <p>Examples of <c>SlaveIP</c> in atom, string, and tuple form:</p> + <p><c>'150.236.16.70', "150,236,16,70", {150,236,16,70}</c>.</p> + <p>Defaults to <c>[]</c>.</p> </item> <tag><c>start_disk_log = true | false</c></tag> <item> <p>Starts the <c>disk_log_server</c> if the parameter is - <c>true</c> (see <seealso marker="disk_log">disk_log(3)</seealso>). - This parameter should be - set to true in an embedded system which uses this service.</p> - <p>The default value is <c>false</c>.</p> + <c>true</c> (see <seealso marker="disk_log"><c>disk_log(3)</c></seealso>). + This parameter is to be set to <c>true</c> in an embedded system + using this service.</p> + <p>Defaults to <c>false</c>.</p> </item> <tag><c>start_pg2 = true | false</c></tag> <item> + <marker id="start_pg2"></marker> <p>Starts the <c>pg2</c> server (see - <seealso marker="pg2">pg2(3)</seealso>) if - the parameter is <c>true</c>. This parameter should be set to - <c>true</c> in an embedded system which uses this service.</p> - <p>The default value is <c>false</c>.</p> + <seealso marker="pg2"><c>pg2(3)</c></seealso>) if + the parameter is <c>true</c>. This parameter is to be set to + <c>true</c> in an embedded system that uses this service.</p> + <p>Defaults to <c>false</c>.</p> </item> <tag><c>start_timer = true | false</c></tag> <item> <p>Starts the <c>timer_server</c> if the parameter is - <c>true</c> (see <seealso marker="stdlib:timer">timer(3)</seealso>). - This parameter should be - set to <c>true</c> in an embedded system which uses this - service.</p> - <p>The default value is <c>false</c>.</p> + <c>true</c> (see <seealso marker="stdlib:timer"><c>stdlib:timer(3)</c></seealso>). + This parameter is to be set to <c>true</c> in an embedded system + using this service.</p> + <p>Defaults to <c>false</c>.</p> </item> <tag><c>shutdown_func = {Mod, Func}</c></tag> <item> @@ -383,7 +371,7 @@ MaxT = TickTime + TickTime / 4</code> <item><c>Func = atom()</c></item> </list> <p>Sets a function that <c>application_controller</c> calls - when it starts to terminate. The function is called as: + when it starts to terminate. The function is called as <c>Mod:Func(Reason)</c>, where <c>Reason</c> is the terminate reason for <c>application_controller</c>, and it must return as soon as possible for <c>application_controller</c> @@ -394,25 +382,25 @@ MaxT = TickTime + TickTime / 4</code> <section> <title>See Also</title> - <p><seealso marker="app">app(4)</seealso>, - <seealso marker="application">application(3)</seealso>, - <seealso marker="code">code(3)</seealso>, - <seealso marker="disk_log">disk_log(3)</seealso>, - <seealso marker="erl_boot_server">erl_boot_server(3)</seealso>, - <seealso marker="erl_ddll">erl_ddll(3)</seealso>, - <seealso marker="error_logger">error_logger(3)</seealso>, - <seealso marker="file">file(3)</seealso>, - <seealso marker="global">global(3)</seealso>, - <seealso marker="global_group">global_group(3)</seealso>, - <seealso marker="heart">heart(3)</seealso>, - <seealso marker="inet">inet(3)</seealso>, - <seealso marker="net_kernel">net_kernel(3)</seealso>, - <seealso marker="os">os(3)</seealso>, - <seealso marker="pg2">pg2(3)</seealso>, - <seealso marker="rpc">rpc(3)</seealso>, - <seealso marker="seq_trace">seq_trace(3)</seealso>, - <seealso marker="stdlib:timer">timer(3)</seealso>, - <seealso marker="user">user(3)</seealso></p> + <p><seealso marker="app"><c>app(4)</c></seealso>, + <seealso marker="application"><c>application(3)</c></seealso>, + <seealso marker="code"><c>code(3)</c></seealso>, + <seealso marker="disk_log"><c>disk_log(3)</c></seealso>, + <seealso marker="erl_boot_server"><c>erl_boot_server(3)</c></seealso>, + <seealso marker="erl_ddll"><c>erl_ddll(3)</c></seealso>, + <seealso marker="error_logger"><c>error_logger(3)</c></seealso>, + <seealso marker="file"><c>file(3)</c></seealso>, + <seealso marker="global"><c>global(3)</c></seealso>, + <seealso marker="global_group"><c>global_group(3)</c></seealso>, + <seealso marker="heart"><c>heart(3)</c></seealso>, + <seealso marker="inet"><c>inet(3)</c></seealso>, + <seealso marker="net_kernel"><c>net_kernel(3)</c></seealso>, + <seealso marker="os"><c>os(3)</c></seealso>, + <seealso marker="pg2"><c>pg2(3)</c></seealso>, + <seealso marker="rpc"><c>rpc(3)</c></seealso>, + <seealso marker="seq_trace"><c>seq_trace(3)</c></seealso>, + <seealso marker="user"><c>user(3)</c></seealso>, + <seealso marker="stdlib:timer"><c>timer(3)</c></seealso></p> </section> </appref> diff --git a/lib/kernel/doc/src/net_adm.xml b/lib/kernel/doc/src/net_adm.xml index 11712f4b42..6957a3b5e4 100644 --- a/lib/kernel/doc/src/net_adm.xml +++ b/lib/kernel/doc/src/net_adm.xml @@ -25,95 +25,105 @@ <title>net_adm</title> <prepared>Claes Wikstrom</prepared> <docno>1</docno> - <date>96-09-10</date> + <date>1996-09-10</date> <rev>A</rev> </header> <module>net_adm</module> - <modulesummary>Various Erlang Net Administration Routines</modulesummary> + <modulesummary>Various Erlang net administration routines.</modulesummary> <description> <p>This module contains various network utility functions.</p> </description> + <funcs> <func> <name name="dns_hostname" arity="1"/> - <fsummary>Official name of a host</fsummary> + <fsummary>Official name of a host.</fsummary> <desc> <p>Returns the official name of <c><anno>Host</anno></c>, or <c>{error, <anno>Host</anno>}</c> if no such name is found. See also - <c>inet(3)</c>.</p> + <seealso marker="inet"><c>inet(3)</c></seealso>.</p> </desc> </func> + <func> <name name="host_file" arity="0"/> - <fsummary>Read the <c>.hosts.erlang</c>file</fsummary> + <fsummary>Read file <c>.hosts.erlang</c>.</fsummary> <desc> - <p>Reads the <c>.hosts.erlang</c> file, see the section - <em>Files</em> below. Returns the hosts in this file as a - list, or returns <c>{error, <anno>Reason</anno>}</c> if the file could not - be read or the Erlang terms on the file could not be interpreted.</p> + <p>Reads file <c>.hosts.erlang</c>, see section + <seealso marker="#files">Files</seealso>. Returns the hosts in this + file as a list. Returns <c>{error, <anno>Reason</anno>}</c> if the + file cannot be read or the Erlang terms on the file cannot be + interpreted.</p> </desc> </func> + <func> <name name="localhost" arity="0"/> - <fsummary>Name of the local host</fsummary> + <fsummary>Name of the local host.</fsummary> <desc> <p>Returns the name of the local host. If Erlang was started - with the <c>-name</c> command line flag, <c><anno>Name</anno></c> is + with command-line flag <c>-name</c>, <c><anno>Name</anno></c> is the fully qualified name.</p> </desc> </func> + <func> <name name="names" arity="0"/> <name name="names" arity="1"/> - <fsummary>Names of Erlang nodes at a host</fsummary> + <fsummary>Names of Erlang nodes at a host.</fsummary> <desc> - <p>Similar to <c>epmd -names</c>, see <c>epmd(1)</c>. - <c><anno>Host</anno></c> defaults to the local host. Returns the names and - associated port numbers of the Erlang nodes that <c>epmd</c> - at the specified host has registered.</p> - <p>Returns <c>{error, address}</c> if <c>epmd</c> is not - running.</p> + <p>Similar to <c>epmd -names</c>, see + <seealso marker="erts:epmd"><c>erts:epmd(1)</c></seealso>. + <c><anno>Host</anno></c> defaults to the local host. Returns the + names and associated port numbers of the Erlang nodes that + <c>epmd</c> registered at the specified host. Returns + <c>{error, address}</c> if <c>epmd</c> is not operational.</p> + <p><em>Example:</em></p> <pre> (arne@dunn)1> <input>net_adm:names().</input> {ok,[{"arne",40262}]}</pre> </desc> </func> + <func> <name name="ping" arity="1"/> - <fsummary>Set up a connection to a node</fsummary> + <fsummary>Set up a connection to a node.</fsummary> <desc> - <p>Tries to set up a connection to <c><anno>Node</anno></c>. Returns - <c>pang</c> if it fails, or <c>pong</c> if it is successful.</p> + <p>Sets up a connection to <c><anno>Node</anno></c>. Returns + <c>pong</c> if it is successful, otherwise <c>pang</c>.</p> </desc> </func> + <func> <name name="world" arity="0"/> <name name="world" arity="1"/> - <fsummary>Lookup and connect to all nodes at all hosts in <c>.hosts.erlang</c></fsummary> + <fsummary>Lookup and connect to all nodes at all hosts in + <c>.hosts.erlang</c>.</fsummary> <type name="verbosity"/> <desc> - <p>This function calls <c>names(Host)</c> for all hosts which + <p>Calls <c>names(Host)</c> for all hosts that are specified in the Erlang host file <c>.hosts.erlang</c>, - collects the replies and then evaluates <c>ping(Node)</c> on - all those nodes. Returns the list of all nodes that were, - successfully pinged.</p> + collects the replies, and then evaluates <c>ping(Node)</c> on + all those nodes. Returns the list of all nodes that are + successfully pinged.</p> <p><c><anno>Arg</anno></c> defaults to <c>silent</c>. - If <c><anno>Arg</anno> == verbose</c>, the function writes information about which - nodes it is pinging to stdout.</p> + If <c><anno>Arg</anno> == verbose</c>, the function writes + information about which nodes it is pinging to <c>stdout</c>.</p> <p>This function can be useful when a node is started, and - the names of the other nodes in the network are not initially - known.</p> - <p>Failure: <c>{error, Reason}</c> if <c>host_file()</c> + the names of the other network nodes are not initially known.</p> + <p>Returns <c>{error, Reason}</c> if <c>host_file()</c> returns <c>{error, Reason}</c>.</p> </desc> </func> + <func> <name name="world_list" arity="1"/> <name name="world_list" arity="2"/> - <fsummary>Lookup and connect to all nodes at specified hosts</fsummary> + <fsummary>Lookup and connect to all nodes at specified hosts.</fsummary> <type name="verbosity"/> <desc> - <p>As <c>world/0,1</c>, but the hosts are given as argument + <p>Same as <seealso marker="#world/1"><c>world/0,1</c></seealso>, + but the hosts are specified as argument instead of being read from <c>.hosts.erlang</c>.</p> </desc> </func> @@ -121,13 +131,14 @@ <section> <title>Files</title> - <p>The <c>.hosts.erlang</c> file consists of a number of host names + <marker id="files"/> + <p>File <c>.hosts.erlang</c> consists of a number of host names written as Erlang terms. It is looked for in the current work directory, the user's home directory, and <c>$OTP_ROOT</c> (the root directory of Erlang/OTP), in that order.</p> - <p>The format of the <c>.hosts.erlang</c> file must be one host - name per line. The host names must be within quotes as shown in - the following example:</p> + <p>The format of file <c>.hosts.erlang</c> must be one host + name per line. The host names must be within quotes.</p> + <p><em>Example:</em></p> <pre> 'super.eua.ericsson.se'. 'renat.eua.ericsson.se'. diff --git a/lib/kernel/doc/src/net_kernel.xml b/lib/kernel/doc/src/net_kernel.xml index 97b20fe94f..f48a534d4f 100644 --- a/lib/kernel/doc/src/net_kernel.xml +++ b/lib/kernel/doc/src/net_kernel.xml @@ -25,41 +25,47 @@ <title>net_kernel</title> <prepared>Claes Wikstrom</prepared> <docno>1</docno> - <date>96-09-10</date> + <date>1996-09-10</date> <rev>A</rev> </header> <module>net_kernel</module> - <modulesummary>Erlang Networking Kernel</modulesummary> + <modulesummary>Erlang networking kernel.</modulesummary> <description> <p>The net kernel is a system process, registered as - <c>net_kernel</c>, which must be running for distributed Erlang + <c>net_kernel</c>, which must be operational for distributed Erlang to work. The purpose of this process is to implement parts of the BIFs <c>spawn/4</c> and <c>spawn_link/4</c>, and to provide monitoring of the network.</p> - <p>An Erlang node is started using the command line flag + <p>An Erlang node is started using command-line flag <c>-name</c> or <c>-sname</c>:</p> -<pre>$ <input>erl -sname foobar</input></pre> + <pre> +$ <input>erl -sname foobar</input></pre> <p>It is also possible to call <c>net_kernel:start([foobar])</c> directly from the normal Erlang shell prompt:</p> -<pre>1> <input>net_kernel:start([foobar, shortnames]).</input> + <pre> +1> <input>net_kernel:start([foobar, shortnames]).</input> {ok,<0.64.0>} (foobar@gringotts)2></pre> - <p>If the node is started with the command line flag <c>-sname</c>, - the node name will be <c>foobar@Host</c>, where <c>Host</c> is + <p>If the node is started with command-line flag <c>-sname</c>, + the node name is <c>foobar@Host</c>, where <c>Host</c> is the short name of the host (not the fully qualified domain name). - If started with the <c>-name</c> flag, <c>Host</c> is the fully - qualified domain name. See <c>erl(1)</c>.</p> + If started with flag <c>-name</c>, the node name is <c>foobar@Host</c>, + where <c>Host</c> is the fully qualified domain name. + For more information, see + <seealso marker="erts:erl"><c>erl</c></seealso>.</p> <p>Normally, connections are established automatically when another node is referenced. This functionality can be disabled - by setting the Kernel configuration parameter + by setting <c>Kernel</c> configuration parameter <c>dist_auto_connect</c> to <c>false</c>, see - <seealso marker="kernel_app">kernel(6)</seealso>. In this case, + <seealso marker="kernel_app"><c>kernel(6)</c></seealso>. In this case, connections must be established explicitly by calling - <c>net_kernel:connect_node/1</c>.</p> - <p>Which nodes are allowed to communicate with each other is handled - by the magic cookie system, see - <seealso marker="doc/reference_manual:distributed">Distributed Erlang</seealso> in the Erlang Reference Manual.</p> + <seealso marker="#connect_node/1"><c>connect_node/1</c></seealso>.</p> + <p>Which nodes that are allowed to communicate with each other is handled + by the magic cookie system, see section + <seealso marker="doc/reference_manual:distributed">Distributed Erlang</seealso> + in the Erlang Reference Manual.</p> </description> + <funcs> <func> <name name="allow" arity="1"/> @@ -77,237 +83,240 @@ an atom.</p> </desc> </func> + <func> <name name="connect_node" arity="1"/> - <fsummary>Establish a connection to a node</fsummary> + <fsummary>Establish a connection to a node.</fsummary> <desc> - <p>Establishes a connection to <c><anno>Node</anno></c>. Returns <c>true</c> - if successful, <c>false</c> if not, and <c>ignored</c> if - the local node is not alive.</p> + <p>Establishes a connection to <c><anno>Node</anno></c>. Returns + <c>true</c> if successful, <c>false</c> if not, and <c>ignored</c> + if the local node is not alive.</p> + </desc> + </func> + + <func> + <name name="get_net_ticktime" arity="0"/> + <fsummary>Get <c>net_ticktime</c>.</fsummary> + <desc> + <p>Gets <c>net_ticktime</c> (see + <seealso marker="kernel_app"><c>kernel(6)</c></seealso>).</p> + <p>Defined return values (<c><anno>Res</anno></c>):</p> + <taglist> + <tag><c><anno>NetTicktime</anno></c></tag> + <item><p><c>net_ticktime</c> is <c><anno>NetTicktime</anno></c> + seconds.</p></item> + <tag><c>{ongoing_change_to, <anno>NetTicktime</anno>}</c></tag> + <item><p><c>net_kernel</c> is currently changing + <c>net_ticktime</c> to <c><anno>NetTicktime</anno></c> + seconds.</p></item> + <tag><c>ignored</c></tag> + <item><p>The local node is not alive.</p></item> + </taglist> </desc> </func> + <func> <name name="monitor_nodes" arity="1"/> <name name="monitor_nodes" arity="2"/> - <fsummary>Subscribe to node status change messages</fsummary> + <fsummary>Subscribe to node status change messages.</fsummary> <desc> <p>The calling process subscribes or unsubscribes to node status change messages. A <c>nodeup</c> message is delivered - to all subscribing process when a new node is connected, and + to all subscribing processes when a new node is connected, and a <c>nodedown</c> message is delivered when a node is disconnected.</p> - <p>If <c><anno>Flag</anno></c> is <c>true</c>, a new subscription is started. - If <c><anno>Flag</anno></c> is <c>false</c>, all previous subscriptions -- - started with the same <c><anno>Options</anno></c> -- are stopped. Two + <p>If <c><anno>Flag</anno></c> is <c>true</c>, a new subscription is + started. If <c><anno>Flag</anno></c> is <c>false</c>, all previous + subscriptions started with the same <c><anno>Options</anno></c> + are stopped. Two option lists are considered the same if they contain the same set of options.</p> - <p>As of <c>kernel</c> version 2.11.4, and <c>erts</c> version + <p>As from <c>Kernel</c> version 2.11.4, and <c>ERTS</c> version 5.5.4, the following is guaranteed:</p> <list type="bulleted"> - <item><c>nodeup</c> messages will be delivered before delivery - of any message from the remote node passed through the - newly established connection.</item> - <item><c>nodedown</c> messages will not be delivered until all - messages from the remote node that have been passed - through the connection have been delivered.</item> + <item><p><c>nodeup</c> messages are delivered before delivery + of any message from the remote node passed through the + newly established connection.</p></item> + <item><p><c>nodedown</c> messages are not delivered until all + messages from the remote node that have been passed + through the connection have been delivered.</p></item> </list> - <p>Note, that this is <em>not</em> guaranteed for <c>kernel</c> + <p>Notice that this is <em>not</em> guaranteed for <c>Kernel</c> versions before 2.11.4.</p> - <p>As of <c>kernel</c> version 2.11.4 subscriptions can also be - made before the <c>net_kernel</c> server has been started, - i.e., <c>net_kernel:monitor_nodes/[1,2]</c> does not return + <p>As from <c>Kernel</c> version 2.11.4, subscriptions can also be + made before the <c>net_kernel</c> server is started, that is, + <c>net_kernel:monitor_nodes/[1,2]</c> does not return <c>ignored</c>.</p> - <p>As of <c>kernel</c> version 2.13, and <c>erts</c> version + <p>As from <c>Kernel</c> version 2.13, and <c>ERTS</c> version 5.7, the following is guaranteed:</p> <list type="bulleted"> - <item><c>nodeup</c> messages will be delivered after the - corresponding node appears in results from - <c>erlang:nodes/X</c>.</item> - <item><c>nodedown</c> messages will be delivered after the - corresponding node has disappeared in results from - <c>erlang:nodes/X</c>.</item> + <item><p><c>nodeup</c> messages are delivered after the + corresponding node appears in results from + <c>erlang:nodes/X</c>.</p></item> + <item><p><c>nodedown</c> messages are delivered after the + corresponding node has disappeared in results from + <c>erlang:nodes/X</c>.</p></item> </list> - <p>Note, that this is <em>not</em> guaranteed for <c>kernel</c> + <p>Notice that this is <em>not</em> guaranteed for <c>Kernel</c> versions before 2.13.</p> <p>The format of the node status change messages depends on - <c><anno>Options</anno></c>. If <c><anno>Options</anno></c> is [], which is the default, - the format is:</p> + <c><anno>Options</anno></c>. If <c><anno>Options</anno></c> is + <c>[]</c>, which is the default, the format is as follows:</p> <code type="none"> {nodeup, Node} | {nodedown, Node} Node = node()</code> - <p>If <c><anno>Options</anno> /= []</c>, the format is:</p> + <p>If <c><anno>Options</anno></c> is not <c>[]</c>, the format is + as follows:</p> <code type="none"> {nodeup, Node, InfoList} | {nodedown, Node, InfoList} Node = node() InfoList = [{Tag, Val}]</code> <p><c>InfoList</c> is a list of tuples. Its contents depends on <c><anno>Options</anno></c>, see below.</p> - <p>Also, when <c>OptionList == []</c> only visible nodes, that + <p>Also, when <c>OptionList == []</c>, only visible nodes, that is, nodes that appear in the result of - <seealso marker="erts:erlang#nodes/0">nodes/0</seealso>, are - monitored.</p> + <seealso marker="erts:erlang#nodes/0"><c>erlang:nodes/0</c></seealso>, + are monitored.</p> <p><c><anno>Option</anno></c> can be any of the following:</p> <taglist> <tag><c>{node_type, NodeType}</c></tag> <item> - <p>Currently valid values for <c>NodeType</c> are:</p> + <p>Valid values for <c>NodeType</c>:</p> <taglist> <tag><c>visible</c></tag> - <item>Subscribe to node status change messages for visible + <item><p>Subscribe to node status change messages for visible nodes only. The tuple <c>{node_type, visible}</c> is - included in <c>InfoList</c>.</item> + included in <c>InfoList</c>.</p></item> <tag><c>hidden</c></tag> - <item>Subscribe to node status change messages for hidden + <item><p>Subscribe to node status change messages for hidden nodes only. The tuple <c>{node_type, hidden}</c> is - included in <c>InfoList</c>.</item> + included in <c>InfoList</c>.</p></item> <tag><c>all</c></tag> - <item>Subscribe to node status change messages for both + <item><p>Subscribe to node status change messages for both visible and hidden nodes. The tuple - <c>{node_type, visible | hidden}</c> is included in - <c>InfoList</c>.</item> + <c>{node_type, visible | hidden}</c> is included in + <c>InfoList</c>.</p></item> </taglist> </item> <tag><c>nodedown_reason</c></tag> <item> <p>The tuple <c>{nodedown_reason, Reason}</c> is included in - <c>InfoList</c> in <c>nodedown</c> messages. <c>Reason</c> - can be:</p> + <c>InfoList</c> in <c>nodedown</c> messages.</p> + <p><c>Reason</c> can be any of the following:</p> <taglist> <tag><c>connection_setup_failed</c></tag> - <item>The connection setup failed (after <c>nodeup</c> - messages had been sent).</item> + <item><p>The connection setup failed (after <c>nodeup</c> + messages were sent).</p></item> <tag><c>no_network</c></tag> - <item>No network available.</item> + <item><p>No network is available.</p></item> <tag><c>net_kernel_terminated</c></tag> - <item>The <c>net_kernel</c> process terminated.</item> + <item><p>The <c>net_kernel</c> process terminated.</p></item> <tag><c>shutdown</c></tag> - <item>Unspecified connection shutdown.</item> + <item><p>Unspecified connection shutdown.</p></item> <tag><c>connection_closed</c></tag> - <item>The connection was closed.</item> + <item><p>The connection was closed.</p></item> <tag><c>disconnect</c></tag> - <item>The connection was disconnected (forced from the - current node).</item> + <item><p>The connection was disconnected (forced from the + current node).</p></item> <tag><c>net_tick_timeout</c></tag> - <item>Net tick timeout.</item> + <item><p>Net tick time-out.</p></item> <tag><c>send_net_tick_failed</c></tag> - <item>Failed to send net tick over the connection.</item> + <item><p>Failed to send net tick over the connection.</p></item> <tag><c>get_status_failed</c></tag> - <item>Status information retrieval from the <c>Port</c> - holding the connection failed.</item> + <item><p>Status information retrieval from the <c>Port</c> + holding the connection failed.</p></item> </taglist> </item> </taglist> </desc> </func> - <func> - <name name="get_net_ticktime" arity="0"/> - <fsummary>Get <c>net_ticktime</c></fsummary> - <desc> - <p>Gets <c>net_ticktime</c> (see - <seealso marker="kernel_app">kernel(6)</seealso>).</p> - <p>Currently defined return values (<c><anno>Res</anno></c>):</p> - <taglist> - <tag><c><anno>NetTicktime</anno></c></tag> - <item> - <p><c>net_ticktime</c> is <c><anno>NetTicktime</anno></c> seconds.</p> - </item> - <tag><c>{ongoing_change_to, <anno>NetTicktime</anno>}</c></tag> - <item> - <p><c>net_kernel</c> is currently changing - <c>net_ticktime</c> to <c><anno>NetTicktime</anno></c> seconds.</p> - </item> - <tag><c>ignored</c></tag> - <item> - <p>The local node is not alive.</p> - </item> - </taglist> - </desc> - </func> + <func> <name name="set_net_ticktime" arity="1"/> <name name="set_net_ticktime" arity="2"/> - <fsummary>Set <c>net_ticktime</c></fsummary> + <fsummary>Set <c>net_ticktime</c>.</fsummary> <desc> <p>Sets <c>net_ticktime</c> (see - <seealso marker="kernel_app">kernel(6)</seealso>) to - <c><anno>NetTicktime</anno></c> seconds. <c><anno>TransitionPeriod</anno></c> defaults - to 60.</p> + <seealso marker="kernel_app"><c>kernel(6)</c></seealso>) to + <c><anno>NetTicktime</anno></c> seconds. + <c><anno>TransitionPeriod</anno></c> defaults to <c>60</c>.</p> <p>Some definitions:</p> <taglist> - <tag>The minimum transition traffic interval (<c>MTTI</c>)</tag> - <item> - <p><c>minimum(<anno>NetTicktime</anno>, PreviousNetTicktime)*1000 div 4</c> milliseconds.</p> - </item> - <tag>The transition period</tag> - <item> - <p>The time of the least number of consecutive <c>MTTI</c>s - to cover <c><anno>TransitionPeriod</anno></c> seconds following - the call to <c>set_net_ticktime/2</c> (i.e. - ((<c><anno>TransitionPeriod</anno>*1000 - 1) div MTTI + 1)*MTTI</c> - milliseconds).</p> - </item> + <tag>Minimum transition traffic interval (<c>MTTI</c>)</tag> + <item><p><c>minimum(<anno>NetTicktime</anno>, + PreviousNetTicktime)*1000 div 4</c> milliseconds.</p></item> + <tag>Transition period</tag> + <item><p>The time of the least number of consecutive <c>MTTI</c>s + to cover <c><anno>TransitionPeriod</anno></c> seconds following + the call to <c>set_net_ticktime/2</c> (that is, + ((<c><anno>TransitionPeriod</anno>*1000 - 1) div MTTI + 1)*MTTI</c> + milliseconds).</p></item> </taglist> - <p>If <c><![CDATA[<anno>NetTicktime</anno> < PreviousNetTicktime]]></c>, the actual - <c>net_ticktime</c> change will be done at the end of - the transition period; otherwise, at the beginning. During - the transition period, <c>net_kernel</c> will ensure that - there will be outgoing traffic on all connections at least + <p>If + <c><![CDATA[NetTicktime < PreviousNetTicktime]]></c>, + the <c>net_ticktime</c> change is done at the end of + the transition period; otherwise at the beginning. During + the transition period, <c>net_kernel</c> ensures that + there is outgoing traffic on all connections at least every <c>MTTI</c> millisecond.</p> <note> - <p>The <c>net_ticktime</c> changes have to be initiated on all + <p>The <c>net_ticktime</c> changes must be initiated on all nodes in the network (with the same <c><anno>NetTicktime</anno></c>) before the end of any transition period on any node; - otherwise, connections may erroneously be disconnected.</p> + otherwise connections can erroneously be disconnected.</p> </note> <p>Returns one of the following:</p> <taglist> <tag><c>unchanged</c></tag> <item> - <p><c>net_ticktime</c> already had the value of - <c><anno>NetTicktime</anno></c> and was left unchanged.</p> + <p><c>net_ticktime</c> already has the value of + <c><anno>NetTicktime</anno></c> and is left unchanged.</p> </item> <tag><c>change_initiated</c></tag> <item> - <p><c>net_kernel</c> has initiated the change of - <c>net_ticktime</c> to <c><anno>NetTicktime</anno></c> seconds.</p> + <p><c>net_kernel</c> initiated the change of + <c>net_ticktime</c> to <c><anno>NetTicktime</anno></c> + seconds.</p> </item> <tag><c>{ongoing_change_to, <anno>NewNetTicktime</anno>}</c></tag> <item> - <p>The request was <em>ignored</em>; because, - <c>net_kernel</c> was busy changing <c>net_ticktime</c> to + <p>The request is <em>ignored</em> because + <c>net_kernel</c> is busy changing <c>net_ticktime</c> to <c><anno>NewNetTicktime</anno></c> seconds.</p> </item> </taglist> </desc> </func> + <func> <name>start([Name]) -> {ok, pid()} | {error, Reason}</name> <name>start([Name, NameType]) -> {ok, pid()} | {error, Reason}</name> <name>start([Name, NameType, Ticktime]) -> {ok, pid()} | {error, Reason}</name> - <fsummary>Turn an Erlang runtime system into a distributed node</fsummary> + <fsummary>Turn an Erlang runtime system into a distributed node.</fsummary> <type> <v>Name = atom()</v> <v>NameType = shortnames | longnames</v> <v>Reason = {already_started, pid()} | term()</v> </type> <desc> - <p>Note that the argument is a list with exactly one, two or - three arguments. <c>NameType</c> defaults to <c>longnames</c> - and <c>Ticktime</c> to 15000.</p> <p>Turns a non-distributed node into a distributed node by starting <c>net_kernel</c> and other necessary processes.</p> + <p>Notice that the argument is a list with exactly one, two, or + three arguments. <c>NameType</c> defaults to <c>longnames</c> + and <c>Ticktime</c> to <c>15000</c>.</p> </desc> </func> + <func> <name name="stop" arity="0"/> - <fsummary>Turn a node into a non-distributed Erlang runtime system</fsummary> + <fsummary>Turn a node into a non-distributed Erlang runtime system.</fsummary> <desc> <p>Turns a distributed node into a non-distributed node. For other nodes in the network, this is the same as the node - going down. Only possible when the net kernel was started - using <c>start/1</c>, otherwise returns - <c>{error, not_allowed}</c>. Returns <c>{error, not_found}</c> - if the local node is not alive.</p> + going down. Only possible when the net kernel was started using + <seealso marker="#start/1"><c>start/1</c></seealso>, + otherwise <c>{error, not_allowed}</c> is returned. Returns + <c>{error, not_found}</c> if the local node is not alive.</p> </desc> </func> </funcs> diff --git a/lib/kernel/doc/src/os.xml b/lib/kernel/doc/src/os.xml index 079254bb93..739ac35d2a 100644 --- a/lib/kernel/doc/src/os.xml +++ b/lib/kernel/doc/src/os.xml @@ -29,98 +29,107 @@ <rev></rev> </header> <module>os</module> - <modulesummary>Operating System Specific Functions</modulesummary> + <modulesummary>Operating system-specific functions.</modulesummary> <description> - <p>The functions in this module are operating system specific. - Careless use of these functions will result in programs that will + <p>The functions in this module are operating system-specific. + Careless use of these functions results in programs that will only run on a specific platform. On the other hand, with careful - use these functions can be of help in enabling a program to run on + use, these functions can be of help in enabling a program to run on most platforms.</p> </description> <funcs> <func> <name name="cmd" arity="1"/> - <fsummary>Execute a command in a shell of the target OS</fsummary> + <fsummary>Execute a command in a shell of the target OS.</fsummary> <desc> - <p>Executes <c><anno>Command</anno></c> in a command shell of the target OS, - captures the standard output of the command and returns this + <p>Executes <c><anno>Command</anno></c> in a command shell of the + target OS, + captures the standard output of the command, and returns this result as a string. This function is a replacement of - the previous <c>unix:cmd/1</c>; on a Unix platform they are - equivalent.</p> - <p>Examples:</p> + the previous function <c>unix:cmd/1</c>; they are equivalent on a + Unix platform.</p> + <p><em>Examples:</em></p> <code type="none"> LsOut = os:cmd("ls"), % on unix platform DirOut = os:cmd("dir"), % on Win32 platform</code> - <p>Note that in some cases, standard output of a command when + <p>Notice that in some cases, standard output of a command when called from another program (for example, <c>os:cmd/1</c>) - may differ, compared to the standard output of the command + can differ, compared with the standard output of the command when called directly from an OS command shell.</p> </desc> </func> + <func> <name name="find_executable" arity="1"/> <name name="find_executable" arity="2"/> - <fsummary>Absolute filename of a program</fsummary> + <fsummary>Absolute filename of a program.</fsummary> <desc> - <p>These two functions look up an executable program given its - name and a search path, in the same way as the underlying - operating system. <c>find_executable/1</c> uses the current - execution path (that is, the environment variable PATH on + <p>These two functions look up an executable program, with the + specified name and a search path, in the same way as the underlying + OS. <c>find_executable/1</c> uses the current + execution path (that is, the environment variable <c>PATH</c> on Unix and Windows).</p> - <p><c><anno>Path</anno></c>, if given, should conform to the syntax of - execution paths on the operating system. The absolute - filename of the executable program <c><anno>Name</anno></c> is returned, - or <c>false</c> if the program was not found.</p> + <p><c><anno>Path</anno></c>, if specified, is to conform to the syntax + of execution paths on the OS. Returns the absolute filename of the + executable program <c><anno>Name</anno></c>, + or <c>false</c> if the program is not found.</p> </desc> </func> + <func> <name name="getenv" arity="0"/> - <fsummary>List all environment variables</fsummary> + <fsummary>List all environment variables.</fsummary> <desc> <p>Returns a list of all environment variables. - Each environment variable is given as a single string on + Each environment variable is expressed as a single string on the format <c>"VarName=Value"</c>, where <c>VarName</c> is the name of the variable and <c>Value</c> its value.</p> - <p>If Unicode file name encoding is in effect (see the <seealso - marker="erts:erl#file_name_encoding">erl manual - page</seealso>), the strings may contain characters with - codepoints > 255.</p> + <p>If Unicode filename encoding is in effect (see the + <seealso marker="erts:erl#file_name_encoding"><c>erl</c> manual + page</seealso>), the strings can contain characters with + codepoints > 255.</p> </desc> </func> + <func> <name name="getenv" arity="1"/> - <fsummary>Get the value of an environment variable</fsummary> + <fsummary>Get the value of an environment variable.</fsummary> <desc> <p>Returns the <c><anno>Value</anno></c> of the environment variable - <c><anno>VarName</anno></c>, or <c>false</c> if the environment variable - is undefined.</p> - <p>If Unicode file name encoding is in effect (see the <seealso - marker="erts:erl#file_name_encoding">erl manual - page</seealso>), the strings (both <c><anno>VarName</anno></c> and - <c><anno>Value</anno></c>) may contain characters with codepoints > 255.</p> + <c><anno>VarName</anno></c>, or <c>false</c> if the environment + variable is undefined.</p> + <p>If Unicode filename encoding is in effect (see the + <seealso marker="erts:erl#file_name_encoding"><c>erl</c> manual + page</seealso>), the strings <c><anno>VarName</anno></c> and + <c><anno>Value</anno></c> can contain characters with + codepoints > 255.</p> </desc> </func> + <func> <name name="getenv" arity="2"/> - <fsummary>Get the value of an environment variable</fsummary> + <fsummary>Get the value of an environment variable.</fsummary> <desc> <p>Returns the <c><anno>Value</anno></c> of the environment variable - <c><anno>VarName</anno></c>, or <c>DefaultValue</c> if the environment variable - is undefined.</p> - <p>If Unicode file name encoding is in effect (see the <seealso - marker="erts:erl#file_name_encoding">erl manual - page</seealso>), the strings (both <c><anno>VarName</anno></c> and - <c><anno>Value</anno></c>) may contain characters with codepoints > 255.</p> + <c><anno>VarName</anno></c>, or <c>DefaultValue</c> if the + environment variable is undefined.</p> + <p>If Unicode filename encoding is in effect (see the + <seealso marker="erts:erl#file_name_encoding"><c>erl</c> manual + page</seealso>), the strings <c><anno>VarName</anno></c> and + <c><anno>Value</anno></c> can contain characters with + codepoints > 255.</p> </desc> </func> + <func> <name name="getpid" arity="0"/> - <fsummary>Return the process identifier of the emulator process</fsummary> + <fsummary>Return the process identifier of the emulator + process.</fsummary> <desc> <p>Returns the process identifier of the current Erlang emulator - in the format most commonly used by the operating system - environment. <c><anno>Value</anno></c> is returned as a string containing + in the format most commonly used by the OS environment. + Returns <c><anno>Value</anno></c> as a string containing the (usually) numerical identifier for a process. On Unix, this is typically the return value of the <c>getpid()</c> system call. On Windows, @@ -128,88 +137,93 @@ DirOut = os:cmd("dir"), % on Win32 platform</code> system call is used.</p> </desc> </func> + <func> <name name="putenv" arity="2"/> - <fsummary>Set a new value for an environment variable</fsummary> + <fsummary>Set a new value for an environment variable.</fsummary> <desc> - <p>Sets a new <c><anno>Value</anno></c> for the environment variable + <p>Sets a new <c><anno>Value</anno></c> for environment variable <c><anno>VarName</anno></c>.</p> - <p>If Unicode filename encoding is in effect (see the <seealso - marker="erts:erl#file_name_encoding">erl manual - page</seealso>), the strings (both <c><anno>VarName</anno></c> and - <c><anno>Value</anno></c>) may contain characters with codepoints > 255.</p> - <p>On Unix platforms, the environment will be set using UTF-8 encoding - if Unicode file name translation is in effect. On Windows the - environment is set using wide character interfaces.</p> + <p>If Unicode filename encoding is in effect (see the + <seealso marker="erts:erl#file_name_encoding"><c>erl</c> manual + page</seealso>), the strings <c><anno>VarName</anno></c> and + <c><anno>Value</anno></c> can contain characters with + codepoints > 255.</p> + <p>On Unix platforms, the environment is set using UTF-8 encoding + if Unicode filename translation is in effect. On Windows, the + environment is set using wide character interfaces.</p> </desc> </func> + <func> <name name="system_time" arity="0"/> - <fsummary>Current OS system time</fsummary> + <fsummary>Current OS system time.</fsummary> <desc> - <p>Returns current + <p>Returns the current <seealso marker="erts:time_correction#OS_System_Time">OS system time</seealso> in <c>native</c> <seealso marker="erts:erlang#type_time_unit">time unit</seealso>.</p> - - <note><p>This time is <em>not</em> a monotonically increasing time.</p></note> + <note><p>This time is <em>not</em> a monotonically increasing time.</p> + </note> </desc> </func> + <func> <name name="system_time" arity="1"/> - <fsummary>Current OS system time</fsummary> + <fsummary>Current OS system time.</fsummary> <desc> - <p>Returns current + <p>Returns the current <seealso marker="erts:time_correction#OS_System_Time">OS system time</seealso> converted into the <c><anno>Unit</anno></c> passed as argument.</p> - - <p>Calling <c>os:system_time(<anno>Unit</anno>)</c> is equivalent to: - <seealso marker="erts:erlang#convert_time_unit/3"><c>erlang:convert_time_unit</c></seealso><c>(</c><seealso marker="#system_time/0"><c>os:system_time()</c></seealso><c>, + <p>Calling <c>os:system_time(<anno>Unit</anno>)</c> is equivalent to + <seealso marker="erts:erlang#convert_time_unit/3"><c>erlang:convert_time_unit</c></seealso>(<seealso marker="#system_time/0"><c>os:system_time()</c></seealso><c>, native, <anno>Unit</anno>)</c>.</p> - - <note><p>This time is <em>not</em> a monotonically increasing time.</p></note> + <note><p>This time is <em>not</em> a monotonically increasing time.</p> + </note> </desc> </func> + <func> <name name="timestamp" arity="0"/> - <fsummary>Current OS system time on the erlang:timestamp/0 format</fsummary> + <fsummary>Current OS system time on the <c>erlang:timestamp/0</c> format.</fsummary> <type_desc variable="Timestamp">Timestamp = {MegaSecs, Secs, MicroSecs}</type_desc> <desc> - <p>Returns current + <p>Returns the current <seealso marker="erts:time_correction#OS_System_Time">OS system time</seealso> - in the same format as <seealso marker="erts:erlang#timestamp/0">erlang:timestamp/0</seealso>. - The tuple can be used together with the function - <seealso marker="stdlib:calendar#now_to_universal_time/1">calendar:now_to_universal_time/1</seealso> - or <seealso marker="stdlib:calendar#now_to_local_time/1">calendar:now_to_local_time/1</seealso> to - get calendar time. Using the calendar time together with the <c>MicroSecs</c> part of the return - tuple from this function allows you to log timestamps in high resolution and consistent with the - time in the rest of the operating system.</p> - <p>Example of code formatting a string in the format "DD Mon YYYY HH:MM:SS.mmmmmm", where - DD is the day of month, Mon is the textual month name, YYYY is the year, HH:MM:SS is the time and - mmmmmm is the microseconds in six positions:</p> -<code> + in the same format as + <seealso marker="erts:erlang#timestamp/0"><c>erlang:timestamp/0</c></seealso>. + The tuple can be used together with function + <seealso marker="stdlib:calendar#now_to_universal_time/1"><c>calendar:now_to_universal_time/1</c></seealso> + or <seealso marker="stdlib:calendar#now_to_local_time/1"><c>calendar:now_to_local_time/1</c></seealso> + to get calendar time. Using the calendar time, together with the + <c>MicroSecs</c> part of the return tuple from this function, allows + you to log time stamps in high resolution and consistent with the + time in the rest of the OS.</p> + <p>Example of code formatting a string in format + "DD Mon YYYY HH:MM:SS.mmmmmm", where DD is the day of month, + Mon is the textual month name, YYYY is the year, HH:MM:SS is the time, + and mmmmmm is the microseconds in six positions:</p> + <code> -module(print_time). -export([format_utc_timestamp/0]). format_utc_timestamp() -> TS = {_,_,Micro} = os:timestamp(), - {{Year,Month,Day},{Hour,Minute,Second}} = - calendar:now_to_universal_time(TS), + {{Year,Month,Day},{Hour,Minute,Second}} = +calendar:now_to_universal_time(TS), Mstr = element(Month,{"Jan","Feb","Mar","Apr","May","Jun","Jul", - "Aug","Sep","Oct","Nov","Dec"}), + "Aug","Sep","Oct","Nov","Dec"}), io_lib:format("~2w ~s ~4w ~2w:~2..0w:~2..0w.~6..0w", - [Day,Mstr,Year,Hour,Minute,Second,Micro]). -</code> - - <p>The module above could be used in the following way:</p> -<pre> + [Day,Mstr,Year,Hour,Minute,Second,Micro]).</code> + <p>This module can be used as follows:</p> + <pre> 1> <input>io:format("~s~n",[print_time:format_utc_timestamp()]).</input> -29 Apr 2009 9:55:30.051711 -</pre> +29 Apr 2009 9:55:30.051711</pre> <p>OS system time can also be retreived by - <seealso marker="#system_time/0"><c>os:system_time/0</c></seealso>, - and <seealso marker="#system_time/1"><c>os:system_time/1</c></seealso>.</p> + <seealso marker="#system_time/0"><c>system_time/0</c></seealso> and + <seealso marker="#system_time/1"><c>system_time/1</c></seealso>.</p> </desc> </func> + <func> <name name="perf_counter" arity="0"/> <fsummary>Returns a performance counter</fsummary> @@ -227,7 +241,7 @@ format_utc_timestamp() -> high resolution timestamp. This counter is read directly from the hardware or operating system with the same guarantees. This means that two consecutive calls to the function are not guaranteed to be monotonic, though it most likely will be. - The performance counter till be converted to the resolution passed as an argument.</p> + The performance counter will be converted to the resolution passed as an argument.</p> <pre>1> <input>T1 = os:perf_counter(1000),receive after 10000 -> ok end,T2 = os:perf_counter(1000).</input> 176525861 2> <input>T2 - T1.</input> @@ -236,41 +250,43 @@ format_utc_timestamp() -> </func> <func> <name name="type" arity="0"/> - <fsummary>Return the OS family and, in some cases, OS name of the current operating system</fsummary> + <fsummary>Return the OS family and, in some cases, the OS name of the + current OS.</fsummary> <desc> - <p>Returns the <c><anno>Osfamily</anno></c> and, in some cases, <c><anno>Osname</anno></c> - of the current operating system.</p> - <p>On Unix, <c><anno>Osname</anno></c> will have same value as + <p>Returns the <c><anno>Osfamily</anno></c> and, in some cases, the + <c><anno>Osname</anno></c> of the current OS.</p> + <p>On Unix, <c><anno>Osname</anno></c> has the same value as <c>uname -s</c> returns, but in lower case. For example, on - Solaris 1 and 2, it will be <c>sunos</c>.</p> - <p>In Windows, <c><anno>Osname</anno></c> will be either <c>nt</c> (on - Windows NT), or <c>windows</c> (on Windows 95).</p> + Solaris 1 and 2, it is <c>sunos</c>.</p> + <p>On Windows, <c><anno>Osname</anno></c> is <c>nt</c>.</p> <note> - <p>Think twice before using this function. Use the - <c>filename</c> module if you want to inspect or build - file names in a portable way. - Avoid matching on the <c><anno>Osname</anno></c> atom.</p> + <p>Think twice before using this function. Use module + <seealso marker="stdlib:filename"><c>filename</c></seealso> + if you want to inspect or build filenames in a portable way. + Avoid matching on atom <c><anno>Osname</anno></c>.</p> </note> </desc> </func> + <func> <name name="unsetenv" arity="1"/> - <fsummary>Delete an environment variable</fsummary> + <fsummary>Delete an environment variable.</fsummary> <desc> <p>Deletes the environment variable <c><anno>VarName</anno></c>.</p> - <p>If Unicode filename encoding is in effect (see the <seealso - marker="erts:erl#file_name_encoding">erl manual - page</seealso>), the string (<c><anno>VarName</anno></c>) may - contain characters with codepoints > 255.</p> + <p>If Unicode filename encoding is in effect (see the + <seealso marker="erts:erl#file_name_encoding"><c>erl</c> manual + page</seealso>), the string <c><anno>VarName</anno></c> can + contain characters with codepoints > 255.</p> </desc> </func> + <func> <name name="version" arity="0"/> - <fsummary>Return the Operating System version</fsummary> + <fsummary>Return the OS versions.</fsummary> <desc> - <p>Returns the operating system version. + <p>Returns the OS version. On most systems, this function returns a tuple, but a string - will be returned instead if the system has versions which + is returned instead if the system has versions that cannot be expressed as three numbers.</p> <note> <p>Think twice before using this function. If you still need diff --git a/lib/kernel/doc/src/pg2.xml b/lib/kernel/doc/src/pg2.xml index 4a7a2d77b1..0631b317b4 100644 --- a/lib/kernel/doc/src/pg2.xml +++ b/lib/kernel/doc/src/pg2.xml @@ -30,135 +30,136 @@ <checked>[email protected]</checked> <date>1997-08-18</date> <rev>A2</rev> - <file>pg2.sgml</file> + <file>pg2.xml</file> </header> <module>pg2</module> - <modulesummary>Distributed Named Process Groups</modulesummary> + <modulesummary>Distributed named process groups.</modulesummary> <description> - <p>This module implements process groups. Each message may be sent - to one, some, or all members of the group. - </p> + <p>This module implements process groups. Each message can be sent + to one, some, or all group members.</p> <p>A group of processes can be accessed by a common name. For example, if there is a group named <c>foobar</c>, there can be a - set of processes (which can be located on different nodes) which + set of processes (which can be located on different nodes) that are all members of the group <c>foobar</c>. There are no special functions for sending a message to the group. Instead, client - functions should be written with the functions - <c>get_members/1</c> and <c>get_local_members/1</c> to find out - which processes are members of the group. Then the message can be - sent to one or more members of the group. - </p> - <p>If a member terminates, it is automatically removed from the - group. - </p> + functions are to be written with the functions + <seealso marker="#get_members/1"><c>get_members/1</c></seealso> and + <seealso marker="#get_local_members/1"><c>get_local_members/1</c></seealso> + to determine which processes are members of the group. + Then the message can be sent to one or more group members.</p> + <p>If a member terminates, it is automatically removed from the group.</p> <warning> - <p>This module is used by the <c>disk_log</c> module for + <p>This module is used by module + <seealso marker="disk_log"><c>disk_log</c></seealso> for managing distributed disk logs. The disk log names are used as - group names, which means that some action may need to be taken + group names, which means that some action can be needed to avoid name clashes.</p> </warning> </description> + <datatypes> <datatype> <name name="name"/> <desc><p>The name of a process group.</p></desc> </datatype> </datatypes> + <funcs> <func> <name name="create" arity="1"/> - <fsummary>Create a new, empty process group</fsummary> + <fsummary>Create a new, empty process group.</fsummary> <desc> <p>Creates a new, empty process group. The group is globally - visible on all nodes. If the group exists, nothing happens. - </p> + visible on all nodes. If the group exists, nothing happens.</p> </desc> </func> + <func> <name name="delete" arity="1"/> - <fsummary>Delete a process group</fsummary> + <fsummary>Delete a process group.</fsummary> <desc> - <p>Deletes a process group. - </p> + <p>Deletes a process group.</p> </desc> </func> + <func> <name name="get_closest_pid" arity="1"/> - <fsummary>Common dispatch function</fsummary> + <fsummary>Common dispatch function.</fsummary> <desc> - <p>This is a useful dispatch function which can be used from + <p>A useful dispatch function that can be used from client functions. It returns a process on the local node, if - such a process exist. Otherwise, it chooses one randomly. - </p> + such a process exists. Otherwise, it selects one randomly.</p> </desc> </func> + <func> - <name name="get_members" arity="1"/> - <fsummary>Return all processes in a group</fsummary> + <name name="get_local_members" arity="1"/> + <fsummary>Return all local processes in a group.</fsummary> <desc> - <p>Returns all processes in the group <c>Name</c>. This - function should be used from within a client function that - accesses the group. It is therefore optimized for speed. - </p> + <p>Returns all processes running on the local node in the + group <c>Name</c>. This function is to be used from + within a client function that accesses the group. It is therefore + optimized for speed.</p> </desc> </func> + <func> - <name name="get_local_members" arity="1"/> - <fsummary>Return all local processes in a group</fsummary> + <name name="get_members" arity="1"/> + <fsummary>Return all processes in a group.</fsummary> <desc> - <p>Returns all processes running on the local node in the - group <c>Name</c>. This function should to be used from - within a client function that accesses the group. It is therefore - optimized for speed. - </p> + <p>Returns all processes in the group <c>Name</c>. This + function is to be used from within a client function that + accesses the group. It is therefore optimized for speed.</p> </desc> </func> + <func> <name name="join" arity="2"/> - <fsummary>Join a process to a group</fsummary> + <fsummary>Join a process to a group.</fsummary> <desc> <p>Joins the process <c>Pid</c> to the group <c>Name</c>. - A process can join a group several times; it must then - leave the group the same number of times. - </p> + A process can join a group many times and must then + leave the group the same number of times.</p> </desc> </func> + <func> <name name="leave" arity="2"/> - <fsummary>Make a process leave a group</fsummary> + <fsummary>Make a process leave a group.</fsummary> <desc> <p>Makes the process <c>Pid</c> leave the group <c>Name</c>. If the process is not a member of the group, <c>ok</c> is - returned. - </p> - </desc> - </func> - <func> - <name name="which_groups" arity="0"/> - <fsummary>Return a list of all known groups</fsummary> - <desc> - <p>Returns a list of all known groups. - </p> + returned.</p> </desc> </func> + <func> <name name="start" arity="0"/> <name name="start_link" arity="0"/> - <fsummary>Start the pg2 server</fsummary> + <fsummary>Start the <c>pg2</c> server.</fsummary> <desc> - <p>Starts the pg2 server. Normally, the server does not need + <p>Starts the <c>pg2</c> server. Normally, the server does not need to be started explicitly, as it is started dynamically if it is needed. This is useful during development, but in a - target system the server should be started explicitly. Use - configuration parameters for <c>kernel</c> for this. - </p> + target system the server is to be started explicitly. Use the + configuration parameters for + <seealso marker="kernel_app#start_pg2"><c>kernel(6)</c></seealso> + for this.</p> + </desc> + </func> + + <func> + <name name="which_groups" arity="0"/> + <fsummary>Return a list of all known groups.</fsummary> + <desc> + <p>Returns a list of all known groups.</p> </desc> </func> </funcs> <section> <title>See Also</title> - <p><seealso marker="kernel_app">kernel(6)</seealso></p> + <p><seealso marker="kernel_app"><c>kernel(6)</c></seealso></p> </section> </erlref> diff --git a/lib/kernel/doc/src/ref_man.xml b/lib/kernel/doc/src/ref_man.xml index 45526a2468..5cd77e0f6f 100644 --- a/lib/kernel/doc/src/ref_man.xml +++ b/lib/kernel/doc/src/ref_man.xml @@ -29,9 +29,7 @@ <rev></rev> </header> <description> - <p>The <em>Kernel</em> application has all the code necessary to run - the Erlang runtime system itself: file servers and code servers - and so on.</p> + </description> <xi:include href="kernel_app.xml"/> <xi:include href="application.xml"/> @@ -45,9 +43,9 @@ <xi:include href="error_handler.xml"/> <xi:include href="error_logger.xml"/> <xi:include href="file.xml"/> + <xi:include href="gen_sctp.xml"/> <xi:include href="gen_tcp.xml"/> <xi:include href="gen_udp.xml"/> - <xi:include href="gen_sctp.xml"/> <xi:include href="global.xml"/> <xi:include href="global_group.xml"/> <xi:include href="heart.xml"/> diff --git a/lib/kernel/doc/src/rpc.xml b/lib/kernel/doc/src/rpc.xml index d815c34eed..8cad9fe4fc 100644 --- a/lib/kernel/doc/src/rpc.xml +++ b/lib/kernel/doc/src/rpc.xml @@ -25,328 +25,388 @@ <title>rpc</title> <prepared>Claes Wikstrom</prepared> <docno>1</docno> - <date>96-09-10</date> + <date>1996-09-10</date> <rev>A</rev> </header> <module>rpc</module> - <modulesummary>Remote Procedure Call Services</modulesummary> + <modulesummary>Remote Procedure Call services.</modulesummary> <description> - <p>This module contains services which are similar to remote - procedure calls. It also contains broadcast facilities and + <p>This module contains services similar to Remote + Procedure Calls. It also contains broadcast facilities and parallel evaluators. A remote procedure call is a method to call a function on a remote node and collect the answer. It is used for collecting information on a remote node, or for running a function with some specific side effects on the remote node.</p> </description> + <datatypes> <datatype> <name name="key"/> <desc> - <p>As returned by <seealso marker="#async_call/4"> - <c>async_call/4</c>.</seealso></p> + <p>As returned by + <seealso marker="#async_call/4"><c>async_call/4</c></seealso>.</p> </desc> </datatype> </datatypes> + <funcs> <func> - <name name="call" arity="4"/> - <fsummary>Evaluate a function call on a node</fsummary> + <name name="abcast" arity="2"/> + <fsummary>Broadcast a message asynchronously to a registered process on + all nodes.</fsummary> <desc> - <p>Evaluates <c>apply(<anno>Module</anno>, <anno>Function</anno>, <anno>Args</anno>)</c> on the node - <c><anno>Node</anno></c> and returns the corresponding value <c><anno>Res</anno></c>, or - <c>{badrpc, <anno>Reason</anno>}</c> if the call fails.</p> + <p>Equivalent to <c>abcast([node()|nodes()], <anno>Name</anno>, + <anno>Msg</anno>)</c>.</p> </desc> </func> + <func> - <name name="call" arity="5"/> - <fsummary>Evaluate a function call on a node</fsummary> + <name name="abcast" arity="3"/> + <fsummary>Broadcast a message asynchronously to a registered process on + specific nodes.</fsummary> <desc> - <p>Evaluates <c>apply(<anno>Module</anno>, <anno>Function</anno>, <anno>Args</anno>)</c> on the node - <c><anno>Node</anno></c> and returns the corresponding value <c><anno>Res</anno></c>, or - <c>{badrpc, <anno>Reason</anno>}</c> if the call fails. <c><anno>Timeout</anno></c> is - a timeout value in milliseconds. If the call times out, - <c><anno>Reason</anno></c> is <c>timeout</c>.</p> - <p>If the reply arrives after the call times out, no message - will contaminate the caller's message queue, since this - function spawns off a middleman process to act as (a void) - destination for such an orphan reply. This feature also makes - this function more expensive than <c>call/4</c> at - the caller's end.</p> + <p>Broadcasts the message <c><anno>Msg</anno></c> asynchronously to + the registered process <c><anno>Name</anno></c> on the specified + nodes.</p> + </desc> + </func> + + <func> + <name name="async_call" arity="4"/> + <fsummary>Evaluate a function call on a node, asynchronous + version.</fsummary> + <desc> + <p>Implements <em>call streams with promises</em>, a type of + RPC that does not suspend the caller until the result is + finished. Instead, a key is returned, which can be used + later to collect the value. The key can be viewed as a + promise to deliver the answer.</p> + <p>In this case, the key <c><anno>Key</anno></c> is returned, which + can be used in a subsequent call to + <seealso marker="#yield/1"><c>yield/1</c></seealso> or + <seealso marker="#nb_yield/1"><c>nb_yield/1,2</c></seealso> + to retrieve the value of evaluating <c>apply(<anno>Module</anno>, + <anno>Function</anno>, <anno>Args</anno>)</c> on node + <c><anno>Node</anno></c>.</p> </desc> </func> + <func> <name name="block_call" arity="4"/> - <fsummary>Evaluate a function call on a node in the RPC server's context</fsummary> + <fsummary>Evaluate a function call on a node in the RPC server's + context.</fsummary> <desc> - <p>Like <c>call/4</c>, but the RPC server at <c><anno>Node</anno></c> does + <p>Same as <seealso marker="#call/4"><c>call/4</c></seealso>, + but the RPC server at <c><anno>Node</anno></c> does not create a separate process to handle the call. Thus, this function can be used if the intention of the call is to block the RPC server from any other incoming requests until - the request has been handled. The function can also be used + the request has been handled. The function can also be used for efficiency reasons when very small fast functions are - evaluated, for example BIFs that are guaranteed not to + evaluated, for example, BIFs that are guaranteed not to suspend.</p> </desc> </func> + <func> <name name="block_call" arity="5"/> - <fsummary>Evaluate a function call on a node in the RPC server's context</fsummary> + <fsummary>Evaluate a function call on a node in the RPC server's + context.</fsummary> <desc> - <p>Like <c>block_call/4</c>, but with a timeout value in - the same manner as <c>call/5</c>.</p> + <p>Same as + <seealso marker="#block_call/4"><c>block_call/4</c></seealso>, + but with a time-out value in the same manner as + <seealso marker="#call/5"><c>call/5</c></seealso>.</p> </desc> </func> + <func> - <name name="async_call" arity="4"/> - <fsummary>Evaluate a function call on a node, asynchronous version</fsummary> + <name name="call" arity="4"/> + <fsummary>Evaluate a function call on a node.</fsummary> <desc> - <p>Implements <em>call streams with promises</em>, a type of - RPC which does not suspend the caller until the result is - finished. Instead, a key is returned which can be used at a - later stage to collect the value. The key can be viewed as a - promise to deliver the answer.</p> - <p>In this case, the key <c><anno>Key</anno></c> is returned, which can be - used in a subsequent call to <c>yield/1</c> or - <c>nb_yield/1,2</c> to retrieve the value of evaluating - <c>apply(<anno>Module</anno>, <anno>Function</anno>, <anno>Args</anno>)</c> on the node <c><anno>Node</anno></c>.</p> + <p>Evaluates <c>apply(<anno>Module</anno>, <anno>Function</anno>, + <anno>Args</anno>)</c> on node <c><anno>Node</anno></c> and returns + the corresponding value <c><anno>Res</anno></c>, or + <c>{badrpc, <anno>Reason</anno>}</c> if the call fails.</p> </desc> </func> + <func> - <name name="yield" arity="1"/> - <fsummary>Deliver the result of evaluating a function call on a node (blocking)</fsummary> + <name name="call" arity="5"/> + <fsummary>Evaluate a function call on a node.</fsummary> <desc> - <p>Returns the promised answer from a previous - <c>async_call/4</c>. If the answer is available, it is - returned immediately. Otherwise, the calling process is - suspended until the answer arrives from <c>Node</c>.</p> + <p>Evaluates <c>apply(<anno>Module</anno>, <anno>Function</anno>, + <anno>Args</anno>)</c> on node <c><anno>Node</anno></c> and returns + the corresponding value <c><anno>Res</anno></c>, or + <c>{badrpc, <anno>Reason</anno>}</c> if the call fails. + <c><anno>Timeout</anno></c> is + a time-out value in milliseconds. If the call times out, + <c><anno>Reason</anno></c> is <c>timeout</c>.</p> + <p>If the reply arrives after the call times out, no message + contaminates the caller's message queue, as this + function spawns off a middleman process to act as (a void) + destination for such an orphan reply. This feature also makes + this function more expensive than <c>call/4</c> at + the caller's end.</p> </desc> </func> + <func> - <name name="nb_yield" arity="1"/> - <fsummary>Deliver the result of evaluating a function call on a node (non-blocking)</fsummary> + <name name="cast" arity="4"/> + <fsummary>Run a function on a node ignoring the result.</fsummary> <desc> - <p>Equivalent to <c>nb_yield(<anno>Key</anno>, 0)</c>.</p> + <p>Evaluates <c>apply(<anno>Module</anno>, <anno>Function</anno>, + <anno>Args</anno>)</c> on node + <c><anno>Node</anno></c>. No response is delivered and the calling + process is not suspended until the evaluation is complete, as + is the case with + <seealso marker="#call/4"><c>call/4,5</c></seealso>.</p> </desc> </func> + <func> - <name name="nb_yield" arity="2"/> - <fsummary>Deliver the result of evaluating a function call on a node (non-blocking)</fsummary> + <name name="eval_everywhere" arity="3"/> + <fsummary>Run a function on all nodes, ignoring the result.</fsummary> <desc> - <p>This is a non-blocking version of <c>yield/1</c>. It returns - the tuple <c>{value, <anno>Val</anno>}</c> when the computation has - finished, or <c>timeout</c> when <c><anno>Timeout</anno></c> milliseconds - has elapsed.</p> + <p>Equivalent to <c>eval_everywhere([node()|nodes()], + <anno>Module</anno>, <anno>Function</anno>, + <anno>Args</anno>)</c>.</p> </desc> </func> + + <func> + <name name="eval_everywhere" arity="4"/> + <fsummary>Run a function on specific nodes, ignoring the + result.</fsummary> + <desc> + <p>Evaluates <c>apply(<anno>Module</anno>, <anno>Function</anno>, + <anno>Args</anno>)</c> on + the specified nodes. No answers are collected.</p> + </desc> + </func> + + <func> + <name name="multi_server_call" arity="2"/> + <fsummary>Interact with the servers on a number of nodes.</fsummary> + <desc> + <p>Equivalent to <c>multi_server_call([node()|nodes()], + <anno>Name</anno>, <anno>Msg</anno>)</c>.</p> + </desc> + </func> + + <func> + <name name="multi_server_call" arity="3"/> + <fsummary>Interact with the servers on a number of nodes.</fsummary> + <desc> + <p>Can be used when interacting with servers called + <c><anno>Name</anno></c> on the specified nodes. It is assumed that + the servers receive messages in the format + <c>{From, <anno>Msg</anno>}</c> and reply using + <c>From ! {<anno>Name</anno>, Node, <anno>Reply</anno>}</c>, where + <c>Node</c> is the name of the node where the server is located. + The function returns <c>{<anno>Replies</anno>, + <anno>BadNodes</anno>}</c>, where <c><anno>Replies</anno></c> is a + list of all <c><anno>Reply</anno></c> values, and + <c><anno>BadNodes</anno></c> is one of the following:</p> + <list type="bulleted"> + <item>A list of the nodes that do not exist</item> + <item>A list of the nodes where the server does not exist</item> + <item>A list of the nodes where the server terminatd before sending + any reply.</item> + </list> + </desc> + </func> + <func> <name name="multicall" arity="3"/> - <fsummary>Evaluate a function call on a number of nodes</fsummary> + <fsummary>Evaluate a function call on a number of nodes.</fsummary> <desc> - <p>Equivalent to <c>multicall([node()|nodes()], <anno>Module</anno>, <anno>Function</anno>, <anno>Args</anno>, infinity)</c>.</p> + <p>Equivalent to <c>multicall([node()|nodes()], <anno>Module</anno>, + <anno>Function</anno>, <anno>Args</anno>, infinity)</c>.</p> </desc> </func> + <func> <name name="multicall" arity="4" clause_i="1"/> - <fsummary>Evaluate a function call on a number of nodes</fsummary> + <fsummary>Evaluate a function call on a number of nodes.</fsummary> <desc> - <p>Equivalent to <c>multicall(<anno>Nodes</anno>, <anno>Module</anno>, <anno>Function</anno>, <anno>Args</anno>, infinity)</c>.</p> + <p>Equivalent to <c>multicall(<anno>Nodes</anno>, <anno>Module</anno>, + <anno>Function</anno>, <anno>Args</anno>, infinity)</c>.</p> </desc> </func> + <func> <name name="multicall" arity="4" clause_i="2"/> - <fsummary>Evaluate a function call on a number of nodes</fsummary> + <fsummary>Evaluate a function call on a number of nodes.</fsummary> <desc> - <p>Equivalent to <c>multicall([node()|nodes()], <anno>Module</anno>, <anno>Function</anno>, <anno>Args</anno>, <anno>Timeout</anno>)</c>.</p> + <p>Equivalent to <c>multicall([node()|nodes()], <anno>Module</anno>, + <anno>Function</anno>, <anno>Args</anno>, + <anno>Timeout</anno>)</c>.</p> </desc> </func> + <func> <name name="multicall" arity="5"/> - <fsummary>Evaluate a function call on a number of nodes</fsummary> + <fsummary>Evaluate a function call on a number of nodes.</fsummary> <desc> - <p>In contrast to an RPC, a multicall is an RPC which is sent + <p>In contrast to an RPC, a multicall is an RPC that is sent concurrently from one client to multiple servers. This is - useful for collecting some information from a set of nodes, + useful for collecting information from a set of nodes, or for calling a function on a set of nodes to achieve some side effects. It is semantically the same as iteratively making a series of RPCs on all the nodes, but the multicall - is faster as all the requests are sent at the same time + is faster, as all the requests are sent at the same time and are collected one by one as they come back.</p> - <p>The function evaluates <c>apply(<anno>Module</anno>, <anno>Function</anno>, <anno>Args</anno>)</c> - on the specified nodes and collects the answers. It returns - <c>{<anno>ResL</anno>, <anno>BadNodes</anno>}</c>, where <c><anno>BadNodes</anno></c> is a list + <p>The function evaluates <c>apply(<anno>Module</anno>, + <anno>Function</anno>, <anno>Args</anno>)</c> + on the specified nodes and collects the answers. It returns + <c>{<anno>ResL</anno>, <anno>BadNodes</anno>}</c>, where + <c><anno>BadNodes</anno></c> is a list of the nodes that terminated or timed out during computation, and <c><anno>ResL</anno></c> is a list of the return values. <c><anno>Timeout</anno></c> is a time (integer) in milliseconds, or <c>infinity</c>.</p> <p>The following example is useful when new object code is to - be loaded on all nodes in the network, and also indicates - some side effects RPCs may produce:</p> + be loaded on all nodes in the network, and indicates + some side effects that RPCs can produce:</p> <code type="none"> -%% Find object code for module Mod -{Mod, Bin, File} = code:get_object_code(Mod), +%% Find object code for module Mod +{Mod, Bin, File} = code:get_object_code(Mod), -%% and load it on all nodes including this one +%% and load it on all nodes including this one {ResL, _} = rpc:multicall(code, load_binary, [Mod, File, Bin]), %% and then maybe check the ResL list.</code> </desc> </func> + <func> - <name name="cast" arity="4"/> - <fsummary>Run a function on a node ignoring the result</fsummary> + <name name="nb_yield" arity="1"/> + <fsummary>Deliver the result of evaluating a function call on a node + (non-blocking).</fsummary> <desc> - <p>Evaluates <c>apply(<anno>Module</anno>, <anno>Function</anno>, <anno>Args</anno>)</c> on the node - <c><anno>Node</anno></c>. No response is delivered and the calling - process is not suspended until the evaluation is complete, as - is the case with <c>call/4,5</c>.</p> + <p>Equivalent to <c>nb_yield(<anno>Key</anno>, 0)</c>.</p> </desc> </func> + <func> - <name name="eval_everywhere" arity="3"/> - <fsummary>Run a function on all nodes, ignoring the result</fsummary> + <name name="nb_yield" arity="2"/> + <fsummary>Deliver the result of evaluating a function call on a node + (non-blocking).</fsummary> <desc> - <p>Equivalent to <c>eval_everywhere([node()|nodes()], <anno>Module</anno>, <anno>Function</anno>, <anno>Args</anno>)</c>.</p> + <p>Non-blocking version of + <seealso marker="#yield/1"><c>yield/1</c></seealso>. It returns + the tuple <c>{value, <anno>Val</anno>}</c> when the computation is + finished, or <c>timeout</c> when <c><anno>Timeout</anno></c> + milliseconds has elapsed.</p> </desc> </func> + <func> - <name name="eval_everywhere" arity="4"/> - <fsummary>Run a function on specific nodes, ignoring the result</fsummary> + <name name="parallel_eval" arity="1"/> + <fsummary>Evaluate many function calls on all nodes in + parallel.</fsummary> <desc> - <p>Evaluates <c>apply(<anno>Module</anno>, <anno>Function</anno>, <anno>Args</anno>)</c> on - the specified nodes. No answers are collected.</p> + <p>Evaluates, for every tuple in <c><anno>FuncCalls</anno></c>, + <c>apply(<anno>Module</anno>, <anno>Function</anno>, + <anno>Args</anno>)</c> on some node in + the network. Returns the list of return values, in the same + order as in <c><anno>FuncCalls</anno></c>.</p> </desc> </func> + <func> - <name name="abcast" arity="2"/> - <fsummary>Broadcast a message asynchronously to a registered process on all nodes</fsummary> + <name name="pinfo" arity="1"/> + <fsummary>Information about a process.</fsummary> <desc> - <p>Equivalent to <c>abcast([node()|nodes()], <anno>Name</anno>, <anno>Msg</anno>)</c>.</p> + <p>Location transparent version of the BIF + <seealso marker="erts:erlang#process_info/1"><c>erlang:process_info/1</c></seealso> in <c>ERTS</c>.</p> </desc> </func> + <func> - <name name="abcast" arity="3"/> - <fsummary>Broadcast a message asynchronously to a registered process on specific nodes</fsummary> + <name name="pinfo" arity="2" clause_i="1"/> + <name name="pinfo" arity="2" clause_i="2"/> + <fsummary>Information about a process.</fsummary> <desc> - <p>Broadcasts the message <c><anno>Msg</anno></c> asynchronously to - the registered process <c><anno>Name</anno></c> on the specified nodes.</p> + <p>Location transparent version of the BIF + <seealso marker="erts:erlang#process_info/2"><c>erlang:process_info/2</c></seealso> in <c>ERTS</c>.</p> + </desc> + </func> + + <func> + <name name="pmap" arity="3"/> + <fsummary>Parallell evaluation of mapping a function over a + list.</fsummary> + <desc> + <p>Evaluates <c>apply(<anno>Module</anno>, <anno>Function</anno>, + [<anno>Elem</anno>|<anno>ExtraArgs</anno>])</c> for every element + <c><anno>Elem</anno></c> in <c><anno>List1</anno></c>, in parallel. + Returns the list of return values, in the same order as in + <c><anno>List1</anno></c>.</p> </desc> </func> + <func> <name name="sbcast" arity="2"/> - <fsummary>Broadcast a message synchronously to a registered process on all nodes</fsummary> + <fsummary>Broadcast a message synchronously to a registered process on + all nodes.</fsummary> <desc> - <p>Equivalent to <c>sbcast([node()|nodes()], <anno>Name</anno>, <anno>Msg</anno>)</c>.</p> + <p>Equivalent to <c>sbcast([node()|nodes()], <anno>Name</anno>, + <anno>Msg</anno>)</c>.</p> </desc> </func> + <func> <name name="sbcast" arity="3"/> - <fsummary>Broadcast a message synchronously to a registered process on specific nodes</fsummary> + <fsummary>Broadcast a message synchronously to a registered process on + specific nodes.</fsummary> <desc> <p>Broadcasts the message <c><anno>Msg</anno></c> synchronously to - the registered process <c><anno>Name</anno></c> on the specified nodes.</p> - <p>Returns <c>{<anno>GoodNodes</anno>, <anno>BadNodes</anno>}</c>, where <c><anno>GoodNodes</anno></c> - is the list of nodes which have <c><anno>Name</anno></c> as a registered - process.</p> + the registered process <c><anno>Name</anno></c> on the specified + nodes.</p> + <p>Returns <c>{<anno>GoodNodes</anno>, <anno>BadNodes</anno>}</c>, + where <c><anno>GoodNodes</anno></c> is the list of nodes that have + <c><anno>Name</anno></c> as a registered process.</p> <p>The function is synchronous in the sense that it is known that all servers have received the message when the call returns. It is not possible to know that the servers have - actually processed the message.</p> + processed the message.</p> <p>Any further messages sent to the servers, after this - function has returned, will be received by all servers after + function has returned, are received by all servers after this message.</p> </desc> </func> + <func> <name name="server_call" arity="4"/> - <fsummary>Interact with a server on a node</fsummary> + <fsummary>Interact with a server on a node.</fsummary> <desc> - <p>This function can be used when interacting with a server - called <c><anno>Name</anno></c> at node <c><anno>Node</anno></c>. It is assumed that - the server receives messages in the format - <c>{From, <anno>Msg</anno>}</c> and replies using <c>From ! {<anno>ReplyWrapper</anno>, <anno>Node</anno>, <anno>Reply</anno>}</c>. This function makes such + <p>Can be used when interacting with a server called + <c><anno>Name</anno></c> on node <c><anno>Node</anno></c>. It is + assumed that the server receives messages in the format + <c>{From, <anno>Msg</anno>}</c> and replies using + <c>From ! {<anno>ReplyWrapper</anno>, <anno>Node</anno>, + <anno>Reply</anno>}</c>. This function makes such a server call and ensures that the entire call is packed into - an atomic transaction which either succeeds or fails. It + an atomic transaction, which either succeeds or fails. It never hangs, unless the server itself hangs.</p> - <p>The function returns the answer <c><anno>Reply</anno></c> as produced by - the server <c><anno>Name</anno></c>, or <c>{error, <anno>Reason</anno>}</c>.</p> - </desc> - </func> - <func> - <name name="multi_server_call" arity="2"/> - <fsummary>Interact with the servers on a number of nodes</fsummary> - <desc> - <p>Equivalent to <c>multi_server_call([node()|nodes()], <anno>Name</anno>, <anno>Msg</anno>)</c>.</p> - </desc> - </func> - <func> - <name name="multi_server_call" arity="3"/> - <fsummary>Interact with the servers on a number of nodes</fsummary> - <desc> - <p>This function can be used when interacting with servers - called <c><anno>Name</anno></c> on the specified nodes. It is assumed that - the servers receive messages in the format <c>{From, <anno>Msg</anno>}</c> - and reply using <c>From ! {<anno>Name</anno>, Node, <anno>Reply</anno>}</c>, where - <c>Node</c> is the name of the node where the server is - located. The function returns <c>{<anno>Replies</anno>, <anno>BadNodes</anno>}</c>, - where <c><anno>Replies</anno></c> is a list of all <c><anno>Reply</anno></c> values and - <c><anno>BadNodes</anno></c> is a list of the nodes which did not exist, or - where the server did not exist, or where the server terminated - before sending any reply.</p> - </desc> - </func> - <func> - <name name="safe_multi_server_call" arity="2"/> - <name name="safe_multi_server_call" arity="3"/> - <fsummary>Interact with the servers on a number of nodes (deprecated)</fsummary> - <desc> - <warning> - <p>This function is deprecated. Use - <c>multi_server_call/2,3</c> instead.</p> - </warning> - <p>In Erlang/OTP R6B and earlier releases, - <c>multi_server_call/2,3</c> could not handle the case - where the remote node exists, but there is no server called - <c><anno>Name</anno></c>. Instead this function had to be used. In - Erlang/OTP R7B and later releases, however, the functions are - equivalent, except for this function being slightly slower.</p> - </desc> - </func> - <func> - <name name="parallel_eval" arity="1"/> - <fsummary>Evaluate several function calls on all nodes in parallel</fsummary> - <desc> - <p>For every tuple in <c><anno>FuncCalls</anno></c>, evaluates - <c>apply(<anno>Module</anno>, <anno>Function</anno>, <anno>Args</anno>)</c> on some node in - the network. Returns the list of return values, in the same - order as in <c><anno>FuncCalls</anno></c>.</p> - </desc> - </func> - <func> - <name name="pmap" arity="3"/> - <fsummary>Parallell evaluation of mapping a function over a list </fsummary> - <desc> - <p>Evaluates <c>apply(<anno>Module</anno>, <anno>Function</anno>, [<anno>Elem</anno>|<anno>ExtraArgs</anno>])</c>, - for every element <c><anno>Elem</anno></c> in <c><anno>List1</anno></c>, in parallel. - Returns the list of return values, in the same order as in - <c><anno>List1</anno></c>.</p> - </desc> - </func> - <func> - <name name="pinfo" arity="1"/> - <fsummary>Information about a process</fsummary> - <desc> - <p>Location transparent version of the BIF - <seealso marker="erts:erlang#process_info/1"> - <c>process_info/1</c></seealso>.</p> + <p>The function returns the answer <c><anno>Reply</anno></c> as + produced by the server <c><anno>Name</anno></c>, or + <c>{error, <anno>Reason</anno>}</c>.</p> </desc> </func> + <func> - <name name="pinfo" arity="2"/> - <fsummary>Information about a process</fsummary> + <name name="yield" arity="1"/> + <fsummary>Deliver the result of evaluating a function call on a node + (blocking).</fsummary> <desc> - <p>Location transparent version of the BIF - <seealso marker="erts:erlang#process_info/2"> - <c>process_info/2</c></seealso>.</p> + <p>Returns the promised answer from a previous + <seealso marker="#async_call/4"><c>async_call/4</c></seealso>. + If the answer is available, it is + returned immediately. Otherwise, the calling process is + suspended until the answer arrives from <c>Node</c>.</p> </desc> </func> </funcs> diff --git a/lib/kernel/doc/src/seq_trace.xml b/lib/kernel/doc/src/seq_trace.xml index dc25e011a0..1feb3fcb07 100644 --- a/lib/kernel/doc/src/seq_trace.xml +++ b/lib/kernel/doc/src/seq_trace.xml @@ -29,24 +29,17 @@ <rev>A</rev> </header> <module>seq_trace</module> - <modulesummary>Sequential Tracing of Messages</modulesummary> + <modulesummary>Sequential tracing of messages.</modulesummary> <description> <p>Sequential tracing makes it possible to trace all messages resulting from one initial message. Sequential tracing is - completely independent of the ordinary tracing in Erlang, which - is controlled by the <c>erlang:trace/3</c> BIF. See the chapter - <seealso marker="#whatis">What is Sequential Tracing</seealso> - below for more information about what sequential tracing is and - how it can be used.</p> - <p><c>seq_trace</c> provides functions which control all aspects of + independent of the ordinary tracing in Erlang, which + is controlled by the <c>erlang:trace/3</c> BIF. For more information + about what sequential tracing is and how it can be used, see section + <seealso marker="#whatis">Sequential Tracing</seealso>.</p> + <p><c>seq_trace</c> provides functions that control all aspects of sequential tracing. There are functions for activation, - deactivation, inspection and for collection of the trace output.</p> - <note> - <p>The implementation of sequential tracing is in beta status. - This means that the programming interface still might undergo - minor adjustments (possibly incompatible) based on feedback - from users.</p> - </note> + deactivation, inspection, and for collection of the trace output.</p> </description> <datatypes> <datatype> @@ -239,20 +232,21 @@ seq_trace:set_token(OldToken), % activate the trace token again </funcs> <section> - <title>Trace Messages Sent To the System Tracer</title> - <p>The format of the messages are:</p> + <title>Trace Messages Sent to the System Tracer</title> + <p>The format of the messages is one of the following, depending on if + flag <c>timestamp</c> of the trace token is set to <c>true</c> or + <c>false</c>:</p> <code type="none"> {seq_trace, Label, SeqTraceInfo, TimeStamp}</code> <p>or</p> <code type="none"> {seq_trace, Label, SeqTraceInfo}</code> - <p>depending on whether the <c>timestamp</c> flag of the trace - token is set to <c>true</c> or <c>false</c>. Where:</p> + <p>Where:</p> <code type="none"> Label = int() TimeStamp = {Seconds, Milliseconds, Microseconds} Seconds = Milliseconds = Microseconds = int()</code> - <p>The <c>SeqTraceInfo</c> can have the following formats:</p> + <p><c>SeqTraceInfo</c> can have the following formats:</p> <taglist> <tag><c>{send, Serial, From, To, Message}</c></tag> <item> @@ -262,141 +256,151 @@ TimeStamp = {Seconds, Milliseconds, Microseconds} <tag><c>{'receive', Serial, From, To, Message}</c></tag> <item> <p>Used when a process <c>To</c> receives a message with a - trace token that has the <c>'receive'</c> flag set to - <c>true</c>.</p> + trace token that has flag <c>'receive'</c> set to <c>true</c>.</p> </item> <tag><c>{print, Serial, From, _, Info}</c></tag> <item> - <p>Used when a process <c>From</c> has called + <p>Used when a process <c>From</c> has called <c>seq_trace:print(Label, TraceInfo)</c> and has a trace - token with the <c>print</c> flag set to <c>true</c> and + token with flag <c>print</c> set to <c>true</c>, and <c>label</c> set to <c>Label</c>.</p> </item> </taglist> <p><c>Serial</c> is a tuple <c>{PreviousSerial, ThisSerial}</c>, - where the first integer <c>PreviousSerial</c> denotes the serial - counter passed in the last received message which carried a trace - token. If the process is the first one in a new sequential trace, - <c>PreviousSerial</c> is set to the value of the process internal - "trace clock". The second integer <c>ThisSerial</c> is the serial - counter that a process sets on outgoing messages and it is based - on the process internal "trace clock" which is incremented by one - before it is attached to the trace token in the message.</p> + where:</p> + <list type="bulleted"> + <item><p>Integer <c>PreviousSerial</c> denotes the serial + counter passed in the last received message that carried a trace + token. If the process is the first in a new sequential trace, + <c>PreviousSerial</c> is set to the value of the process internal + "trace clock".</p></item> + <item><p>Integer <c>ThisSerial</c> is the serial + counter that a process sets on outgoing messages. It is based + on the process internal "trace clock", which is incremented by one + before it is attached to the trace token in the message.</p></item> + </list> </section> <section> <marker id="whatis"></marker> - <title>What is Sequential Tracing</title> + <title>Sequential Tracing</title> <p>Sequential tracing is a way to trace a sequence of messages sent between different local or remote processes, where the sequence - is initiated by one single message. In short it works like this:</p> + is initiated by a single message. In short, it works as follows:</p> <p>Each process has a <em>trace token</em>, which can be empty or - not empty. When not empty the trace token can be seen as + not empty. When not empty, the trace token can be seen as the tuple <c>{Label, Flags, Serial, From}</c>. The trace token is passed invisibly with each message.</p> - <p>In order to start a sequential trace the user must explicitly set + <p>To start a sequential trace, the user must explicitly set the trace token in the process that will send the first message in a sequence.</p> <p>The trace token of a process is set each time the process matches a message in a receive statement, according to the trace token carried by the received message, empty or not.</p> - <p>On each Erlang node a process can be set as the <em>system tracer</em>. This process will receive trace messages each time + <p>On each Erlang node, a process can be set as the <em>system tracer</em>. + This process receives trace messages each time a message with a trace token is sent or received (if the trace token flag <c>send</c> or <c>'receive'</c> is set). The system - tracer can then print each trace event, write it to a file or + tracer can then print each trace event, write it to a file, or whatever suitable.</p> <note> - <p>The system tracer will only receive those trace events that + <p>The system tracer only receives those trace events that occur locally within the Erlang node. To get the whole picture - of a sequential trace that involves processes on several Erlang + of a sequential trace, involving processes on many Erlang nodes, the output from the system tracer on each involved node - must be merged (off line).</p> + must be merged (offline).</p> </note> - <p>In the following sections Sequential Tracing and its most - fundamental concepts are described.</p> + <p>The following sections describe sequential tracing and its most + fundamental concepts.</p> </section> <section> <title>Trace Token</title> - <p>Each process has a current trace token. Initially the token is + <p>Each process has a current trace token. Initially, the token is empty. When the process sends a message to another process, a - copy of the current token will be sent "invisibly" along with + copy of the current token is sent "invisibly" along with the message.</p> - <p>The current token of a process is set in two ways, either</p> - <list type="ordered"> + <p>The current token of a process is set in one of the following two + ways:</p> + <list type="bulleted"> <item> - <p>explicitly by the process itself, through a call to - <c>seq_trace:set_token</c>, or</p> + <p>Explicitly by the process itself, through a call to + <c>seq_trace:set_token/1,2</c></p> </item> <item> - <p>when a message is received.</p> + <p>When a message is received</p> </item> </list> - <p>In both cases the current token will be set. In particular, if - the token of a message received is empty, the current token of + <p>In both cases, the current token is set. In particular, if + the token of a received message is empty, the current token of the process is set to empty.</p> - <p>A trace token contains a label, and a set of flags. Both - the label and the flags are set in 1 and 2 above.</p> + <p>A trace token contains a label and a set of flags. Both + the label and the flags are set in both alternatives above.</p> </section> <section> <title>Serial</title> - <p>The trace token contains a component which is called - <c>serial</c>. It consists of two integers <c>Previous</c> and + <p>The trace token contains a component called + <c>serial</c>. It consists of two integers, <c>Previous</c> and <c>Current</c>. The purpose is to uniquely identify each traced - event within a trace sequence and to order the messages - chronologically and in the different branches if any.</p> + event within a trace sequence, as well as to order the messages + chronologically and in the different branches, if any.</p> <p>The algorithm for updating <c>Serial</c> can be described as follows:</p> - <p>Let each process have two counters <c>prev_cnt</c> and - <c>curr_cnt</c> which both are set to 0 when a process is created. + <p>Let each process have two counters, <c>prev_cnt</c> and + <c>curr_cnt</c>, both are set to <c>0</c> when a process is created. The counters are updated at the following occasions:</p> <list type="bulleted"> <item> - <p><em>When the process is about to send a message and the trace token is not empty.</em></p> + <p><em>When the process is about to send a message and the trace token + is not empty.</em></p> <p>Let the serial of the trace token be <c>tprev</c> and - <c>tcurr</c>. <br></br> -<c>curr_cnt := curr_cnt + 1</c> <br></br> -<c>tprev := prev_cnt</c> <br></br> -<c>tcurr := curr_cnt</c></p> + <c>tcurr</c>.</p> + <pre> +curr_cnt := curr_cnt + 1 +tprev := prev_cnt +tcurr := curr_cnt</pre> <p>The trace token with <c>tprev</c> and <c>tcurr</c> is then passed along with the message.</p> </item> <item> - <p><em>When the process calls</em><c>seq_trace:print(Label, Info)</c>, <em>Label matches the label part of the trace token and the trace token print flag is true.</em></p> - <p>The same algorithm as for send above.</p> + <p><em>When the process calls</em> <c>seq_trace:print(Label, Info)</c>, + <c>Label</c> <em>matches the label part of the trace token and the + trace token print flag is <c>true</c>.</em></p> + <p>The algorithm is the same as for send above.</p> </item> <item> - <p><em>When a message is received and contains a nonempty trace token.</em></p> + <p><em>When a message is received and contains a non-empty trace + token.</em></p> <p>The process trace token is set to the trace token from the message.</p> <p>Let the serial of the trace token be <c>tprev</c> and - <c>tcurr</c>. <br></br> -<c><![CDATA[if (curr_cnt < tcurr )]]></c> <br></br> - - <c>curr_cnt := tcurr</c> <br></br> -<c>prev_cnt := tcurr</c></p> + <c>tcurr</c>.</p> + <code> +<![CDATA[if (curr_cnt < tcurr )]]> + curr_cnt := tcurr +prev_cnt := tcurr</code> </item> </list> - <p>The <c>curr_cnt</c> of a process is incremented each time + <p><c>curr_cnt</c> of a process is incremented each time the process is involved in a sequential trace. The counter can reach its limit (27 bits) if a process is very long-lived and is - involved in much sequential tracing. If the counter overflows it - will not be possible to use the serial for ordering of the trace - events. To prevent the counter from overflowing in the middle of - a sequential trace the function <c>seq_trace:reset_trace/0</c> - can be called to reset the <c>prev_cnt</c> and <c>curr_cnt</c> of - all processes in the Erlang node. This function will also set all - trace tokens in processes and their message queues to empty and - will thus stop all ongoing sequential tracing.</p> + involved in much sequential tracing. If the counter overflows, the + serial for ordering of the trace events cannot be used. To prevent + the counter from overflowing in the middle of + a sequential trace, function <c>seq_trace:reset_trace/0</c> + can be called to reset <c>prev_cnt</c> and <c>curr_cnt</c> of + all processes in the Erlang node. This function also sets all + trace tokens in processes and their message queues to empty, and + thus stops all ongoing sequential tracing.</p> </section> <section> - <title>Performance considerations</title> - <p>The performance degradation for a system which is enabled for - Sequential Tracing is negligible as long as no tracing is - activated. When tracing is activated there will of course be an - extra cost for each traced message but all other messages will be + <title>Performance Considerations</title> + <p>The performance degradation for a system that is enabled for + sequential tracing is negligible as long as no tracing is + activated. When tracing is activated, there is an + extra cost for each traced message, but all other messages are unaffected.</p> </section> @@ -404,13 +408,13 @@ TimeStamp = {Seconds, Milliseconds, Microseconds} <title>Ports</title> <p>Sequential tracing is not performed across ports.</p> <p>If the user for some reason wants to pass the trace token to a - port this has to be done manually in the code of the port + port, this must be done manually in the code of the port controlling process. The port controlling processes have to check the appropriate sequential trace settings (as obtained from - <c>seq_trace:get_token/1</c> and include trace information in + <c>seq_trace:get_token/1</c>) and include trace information in the message data sent to their respective ports.</p> <p>Similarly, for messages received from a port, a port controller - has to retrieve trace specific information, and set appropriate + has to retrieve trace-specific information, and set appropriate sequential trace flags through calls to <c>seq_trace:set_token/2</c>.</p> </section> @@ -418,23 +422,23 @@ TimeStamp = {Seconds, Milliseconds, Microseconds} <section> <title>Distribution</title> <p>Sequential tracing between nodes is performed transparently. - This applies to C-nodes built with Erl_Interface too. A C-node - built with Erl_Interface only maintains one trace token, which - means that the C-node will appear as one process from + This applies to C-nodes built with <c>Erl_Interface</c> too. A C-node + built with <c>Erl_Interface</c> only maintains one trace token, which + means that the C-node appears as one process from the sequential tracing point of view.</p> - <p>In order to be able to perform sequential tracing between + <p>To be able to perform sequential tracing between distributed Erlang nodes, the distribution protocol has been - extended (in a backward compatible way). An Erlang node which - supports sequential tracing can communicate with an older - (OTP R3B) node but messages passed within that node can of course + extended (in a backward compatible way). An Erlang node + supporting sequential tracing can communicate with an older + (Erlang/OTP R3B) node but messages passed within that node can not be traced.</p> </section> <section> - <title>Example of Usage</title> - <p>The example shown here will give rough idea of how the new - primitives can be used and what kind of output it will produce.</p> - <p>Assume that we have an initiating process with + <title>Example of Use</title> + <p>This example gives a rough idea of how the new + primitives can be used and what kind of output it produces.</p> + <p>Assume that you have an initiating process with <c><![CDATA[Pid == <0.30.0>]]></c> like this:</p> <code type="none"> -module(seqex). @@ -463,8 +467,8 @@ loop() -> PortController ! {ack,Ack} end, loop().</code> - <p>A possible output from the system's sequential_tracer (inspired - by AXE-10 and MD-110) could look like:</p> + <p>A possible output from the system's <c>sequential_tracer</c> can be + like this:</p> <pre> 17:<0.30.0> Info {0,1} WITH "**** Trace Started ****" @@ -475,7 +479,7 @@ loop() -> 17:<0.30.0> Received {2,4} FROM <0.31.0> WITH {ack,{received,the_message}}</pre> <p>The implementation of a system tracer process that produces - the printout above could look like this:</p> + this printout can look like this:</p> <code type="none"> tracer() -> receive @@ -502,16 +506,15 @@ print_trace({'receive',Serial,From,To,Message}) -> print_trace({send,Serial,From,To,Message}) -> io:format("~p Sent ~p TO ~p WITH~n~p~n", [From,Serial,To,Message]).</code> - <p>The code that creates a process that runs the tracer function - above and sets that process as the system tracer could look like - this:</p> + <p>The code that creates a process that runs this tracer function + and sets that process as the system tracer can look like this:</p> <code type="none"> start() -> Pid = spawn(?MODULE,tracer,[]), seq_trace:set_system_tracer(Pid), % set Pid as the system tracer ok.</code> - <p>With a function like <c>test/0</c> below the whole example can be - started.</p> + <p>With a function like <c>test/0</c>, the whole example can be + started:</p> <code type="none"> test() -> P = spawn(?MODULE, loop, [port]), diff --git a/lib/kernel/doc/src/user.xml b/lib/kernel/doc/src/user.xml index a11329f99a..38eac1c221 100644 --- a/lib/kernel/doc/src/user.xml +++ b/lib/kernel/doc/src/user.xml @@ -27,13 +27,13 @@ <title>user</title> <prepared>Robert Virding</prepared> <docno>1</docno> - <date>96-10-10</date> + <date>1996-10-10</date> <rev>A</rev> </header> <module>user</module> - <modulesummary>Standard I/O Server</modulesummary> + <modulesummary>Standard I/O server.</modulesummary> <description> - <p><c>user</c> is a server which responds to all the messages + <p><c>user</c> is a server that responds to all messages defined in the I/O interface. The code in <c>user.erl</c> can be used as a model for building alternative I/O servers.</p> </description> diff --git a/lib/kernel/doc/src/wrap_log_reader.xml b/lib/kernel/doc/src/wrap_log_reader.xml index 8c2fa91a1d..7fb9c1c023 100644 --- a/lib/kernel/doc/src/wrap_log_reader.xml +++ b/lib/kernel/doc/src/wrap_log_reader.xml @@ -26,39 +26,43 @@ <prepared>Esko Vierumäki</prepared> <responsible>Esko Vierumäki</responsible> <docno></docno> - <approved>nobody</approved> - <checked>no</checked> - <date>98-09-21</date> + <approved></approved> + <checked></checked> + <date>1998-09-21</date> <rev>A</rev> <file>wrap_log_reader.sgml</file> </header> <module>wrap_log_reader</module> - <modulesummary>A function to read internally formatted wrap disk logs</modulesummary> + <modulesummary>A service to read internally formatted wrap disk logs. + </modulesummary> <description> - <p><c>wrap_log_reader</c> is a function to read internally formatted - wrap disk logs, refer to disk_log(3). <c>wrap_log_reader</c> does not - interfere with disk_log activities; there is however a known bug in this - version of the <c>wrap_log_reader</c>, see chapter <c>bugs</c> below. - </p> - <p>A wrap disk log file consists of several files, called index files. - A log file can be opened and closed. It is also possible to open just one index file - separately. If an non-existent or a non-internally formatted file is opened, - an error message is returned. If the file is corrupt, no attempt to repair it - will be done but an error message is returned. - </p> - <p>If a log is configured to be distributed, there is a possibility that all items - are not loggen on all nodes. <c>wrap_log_reader</c> does only read the log on - the called node, it is entirely up to the user to be sure that all items are read. - </p> + <p>This module makes it possible to read internally formatted + wrap disk logs, see + <seealso marker="disk_log"><c>disk_log(3)</c></seealso>. + <c>wrap_log_reader</c> does not + interfere with <c>disk_log</c> activities; there is however a bug in this + version of the <c>wrap_log_reader</c>, see section + <seealso marker="#bugs">Known Limitations</seealso>.</p> + <p>A wrap disk log file consists of many files, called index files. A log + file can be opened and closed. Also, a single index file can be opened + separately. If a non-existent or non-internally formatted file is opened, + an error message is returned. If the file is corrupt, no attempt is made + to repair it, but an error message is returned.</p> + <p>If a log is configured to be distributed, it is possible that all items + are not logged on all nodes. <c>wrap_log_reader</c> only reads the log on + the called node; it is up to the user to be sure that all items + are read.</p> </description> + <datatypes> <datatype> <name name="continuation"/> - <desc><p>Continuation returned by - <c>open/1,2</c> or <c>chunk/1,2</c>.</p> + <desc> + <p>Continuation returned by <c>open/1,2</c> or <c>chunk/1,2</c>.</p> </desc> </datatype> </datatypes> + <funcs> <func> <name name="chunk" arity="1"/> @@ -66,87 +70,83 @@ <fsummary>Read a chunk of objects written to a wrap log.</fsummary> <type name="chunk_ret"/> <desc> - <p>This function makes it possible to efficiently read the - terms which have been appended to a log. It minimises disk - I/O by reading large 8K chunks from the file. - </p> - <p>The first time <c>chunk</c> is called an initial - continuation returned from the <c>open/1</c>, <c>open/2</c> must be provided. - </p> + <p>Enables to efficiently read the + terms that are appended to a log. Minimises disk + I/O by reading 64 kilobyte chunks from the file.</p> + <p>The first time <c>chunk()</c> is called, an initial + continuation returned from <c>open/1</c> or <c>open/2</c> must be + provided.</p> <p>When <c>chunk/3</c> is called, <c><anno>N</anno></c> controls the maximum number of terms that are read from the log in each - chunk. Default is <c>infinity</c>, which means that all the + chunk. Defaults to <c>infinity</c>, which means that all the terms contained in the 8K chunk are read. If less than - <c><anno>N</anno></c> terms are returned, this does not necessarily mean - that end of file is reached. - </p> - <p>The <c>chunk</c> function returns a tuple - <c>{<anno>Continuation2</anno>, <anno>Terms</anno>}</c>, where <c><anno>Terms</anno></c> is a list + <c><anno>N</anno></c> terms are returned, this does not necessarily + mean that end of file is reached.</p> + <p>Returns a tuple <c>{<anno>Continuation2</anno>, + <anno>Terms</anno>}</c>, where <c><anno>Terms</anno></c> is a list of terms found in the log. <c><anno>Continuation2</anno></c> is yet - another continuation which must be passed on into any - subsequent calls to <c>chunk</c>. With a series of calls to - <c>chunk</c> it is then possible to extract all terms from a - log. - </p> - <p>The <c>chunk</c> function returns a tuple - <c>{<anno>Continuation2</anno>, <anno>Terms</anno>, <anno>Badbytes</anno>}</c> if the log is opened - in read only mode and the read chunk is corrupt. <c><anno>Badbytes</anno></c> + another continuation that must be passed on to any + subsequent calls to <c>chunk()</c>. With a series of calls to + <c>chunk()</c>, it is then possible to extract all terms from a log.</p> + <p>Returns a tuple <c>{<anno>Continuation2</anno>, + <anno>Terms</anno>, <anno>Badbytes</anno>}</c> if the log is opened + in read only mode and the read chunk is corrupt. + <c><anno>Badbytes</anno></c> indicates the number of non-Erlang terms found in the chunk. - Note also that the log is not repaired. - </p> - <p><c>chunk</c> returns <c>{<anno>Continuation2</anno>, eof}</c> when the end of the log is - reached, and <c>{error, <anno>Reason</anno>}</c> if an error occurs. - </p> - <p>The returned continuation may or may not be valid in the next call to - <c>chunk</c>. This is because the log may wrap and delete - the file into which the continuation points. To make sure - this does not happen, the log can be blocked during the - search. - </p> + Notice that the log is not repaired.</p> + <p>Returns <c>{<anno>Continuation2</anno>, eof}</c> when + the end of the log is reached, and <c>{error, <anno>Reason</anno>}</c> + if an error occurs.</p> + <p>The returned continuation either is or is not valid in the next call + to this function. This is because the log can wrap and delete + the file into which the continuation points. To ensure + this does not occur, the log can be blocked during the search.</p> </desc> </func> + <func> <name name="close" arity="1"/> - <fsummary>Close a log</fsummary> + <fsummary>Close a log.</fsummary> <desc> - <p>This function closes a log file properly. - </p> + <p>Closes a log file properly.</p> </desc> </func> + <func> <name name="open" arity="1"/> <name name="open" arity="2"/> - <fsummary>Open a log file</fsummary> + <fsummary>Open a log file.</fsummary> <type name="open_ret"/> <desc> - <p><c><anno>Filename</anno></c> specifies the name of the file which is to be read. </p> - <p><c><anno>N</anno></c> specifies the index of the file which is to be read. - If <c><anno>N</anno></c> is omitted the whole wrap log file will be read; if it - is specified only the specified index file will be read. - </p> - <p>The <c>open</c> function returns <c>{ok, <anno>Continuation</anno>}</c> if the - log/index file was successfully opened. The <c><anno>Continuation</anno></c> - is to be used when chunking or closing the file. - </p> - <p>The function returns <c>{error, <anno>Reason</anno>}</c> for all errors. - </p> + <p><c><anno>Filename</anno></c> specifies the name of the file to be + read.</p> + <p><c><anno>N</anno></c> specifies the index of the file to be read. + If <c><anno>N</anno></c> is omitted, the whole wrap log file is read; + if it is specified, only the specified index file is read.</p> + <p>Returns <c>{ok, <anno>Continuation</anno>}</c> if the + log/index file is opened successfully. + <c><anno>Continuation</anno></c> + is to be used when chunking or closing the file.</p> + <p>Returns <c>{error, <anno>Reason</anno>}</c> for all errors.</p> </desc> </func> </funcs> <section> - <title>Bugs</title> - <p>This version of the <c>wrap_log_reader</c> does not detect if the <c>disk_log</c> - wraps to a new index file between a <c>wrap_log_reader:open</c> and the first - <c>wrap_log_reader:chunk</c>. - In this case the chuck will actually read the last logged items in the log file, - because the opened index file was truncated by the <c>disk_log</c>. - </p> + <title>Known Limitations</title> + <marker id="bugs"/> + <p>This version of <c>wrap_log_reader</c> does not detect if + <c>disk_log</c> wraps to a new index file between a call to + <c>wrap_log_reader:open()</c> and the first call to + <c>wrap_log_reader:chunk()</c>. + If this occurs, the call to <c>chunk()</c> reads the last logged + items in the log file, as the opened index file was truncated by + <c>disk_log</c>.</p> </section> <section> <title>See Also</title> - <p><seealso marker="disk_log">disk_log(3)</seealso></p> + <p><seealso marker="disk_log"><c>disk_log(3)</c></seealso></p> </section> </erlref> diff --git a/lib/kernel/doc/src/zlib_stub.xml b/lib/kernel/doc/src/zlib_stub.xml index ac1112ad32..b111581b10 100644 --- a/lib/kernel/doc/src/zlib_stub.xml +++ b/lib/kernel/doc/src/zlib_stub.xml @@ -31,13 +31,9 @@ <rev>A</rev> </header> <module>zlib</module> - <modulesummary>Zlib Compression interface.</modulesummary> - <description><p> - - The module zlib is moved to the runtime system - application. Please see <seealso - marker="erts:zlib">zlib(3)</seealso> in the - erts reference manual instead. - - </p></description> + <modulesummary>Zlib compression interface.</modulesummary> + <description> + <p>This module is moved to the + <seealso marker="erts:zlib"><c>ERTS</c></seealso> application.</p> + </description> </erlref> |