diff options
Diffstat (limited to 'erts/doc/src/erlang.xml')
| -rw-r--r-- | erts/doc/src/erlang.xml | 7455 |
1 files changed, 3868 insertions, 3587 deletions
diff --git a/erts/doc/src/erlang.xml b/erts/doc/src/erlang.xml index 6289f033b2..51ebddc155 100644 --- a/erts/doc/src/erlang.xml +++ b/erts/doc/src/erlang.xml @@ -32,18 +32,21 @@ <module>erlang</module> <modulesummary>The Erlang BIFs.</modulesummary> <description> - <p>By convention, most Built-In Functions (BIFs) are seen as being + <p>By convention, most Built-In Functions (BIFs) are included in this module. Some of the BIFs are viewed more or less as part of the Erlang programming language and are <em>auto-imported</em>. Thus, it is not necessary to specify the module name. For example, the calls <c>atom_to_list(Erlang)</c> and <c>erlang:atom_to_list(Erlang)</c> are identical.</p> + <p>Auto-imported BIFs are listed without module prefix. BIFs listed with module prefix are not auto-imported.</p> + <p>BIFs can fail for various reasons. All BIFs fail with reason <c>badarg</c> if they are called with arguments of an incorrect type. The other reasons are described in the description of each individual BIF.</p> + <p>Some BIFs can be used in guard tests and are marked with "Allowed in guard tests".</p> </description> @@ -53,100 +56,104 @@ <name>ext_binary()</name> <desc> <p>A binary data object, structured according to - the Erlang external term format.</p> + the Erlang external term format.</p> </desc> </datatype> - <datatype> <name name="message_queue_data"></name> - <desc><p>See <seealso marker="#process_flag_message_queue_data"><c>erlang:process_flag(message_queue_data, MQD)</c></seealso>.</p> + <desc> + <p>See <seealso marker="#process_flag_message_queue_data"> + <c>process_flag(message_queue_data, MQD)</c></seealso>.</p> </desc> </datatype> - <datatype> <name name="timestamp"></name> - <desc><p>See <seealso marker="#timestamp/0">erlang:timestamp/0</seealso>.</p> + <desc> + <p>See <seealso marker="#timestamp/0"> + <c>erlang:timestamp/0</c></seealso>.</p> </desc> </datatype> <datatype> <name name="time_unit"></name> - <desc><p><marker id="type_time_unit"/> - Supported time unit representations:</p> + <desc> + <marker id="type_time_unit"/> + <p>Supported time unit representations:</p> <taglist> - <tag><c>PartsPerSecond :: integer() >= 1</c></tag> - <item><p>Time unit expressed in parts per second. That is, - the time unit equals <c>1/PartsPerSecond</c> second.</p></item> - - <tag><c>seconds</c></tag> - <item><p>Symbolic representation of the time unit - represented by the integer <c>1</c>.</p></item> - - <tag><c>milli_seconds</c></tag> - <item><p>Symbolic representation of the time unit - represented by the integer <c>1000</c>.</p></item> - - <tag><c>micro_seconds</c></tag> - <item><p>Symbolic representation of the time unit - represented by the integer <c>1000000</c>.</p></item> - - <tag><c>nano_seconds</c></tag> - <item><p>Symbolic representation of the time unit - represented by the integer <c>1000000000</c>.</p></item> - - <tag><c>native</c></tag> - <item><p>Symbolic representation of the native time unit - used by the Erlang runtime system.</p> - - <p>The <c>native</c> time unit is determined at - runtime system start, and remains the same until - the runtime system terminates. If a runtime system - is stopped and then started again (even on the same - machine), the <c>native</c> time unit of the new - runtime system instance can differ from the - <c>native</c> time unit of the old runtime system - instance.</p> - - <p>One can get an approximation of the <c>native</c> - time unit by calling <c>erlang:convert_time_unit(1, - seconds, native)</c>. The result equals the number - of whole <c>native</c> time units per second. In case - the number of <c>native</c> time units per second does - not add up to a whole number, the result is rounded downwards.</p> - - <note> - <p>The value of the <c>native</c> time unit gives - you more or less no information at all about the - quality of time values. It sets a limit for - the - <seealso marker="time_correction#Time_Resolution">resolution</seealso> - as well as for the - <seealso marker="time_correction#Time_Precision">precision</seealso> - of time values, - but it gives absolutely no information at all about the - <seealso marker="time_correction#Time_Accuracy">accuracy</seealso> - of time values. The resolution of the <c>native</c> time - unit and the resolution of time values can differ - significantly.</p> - </note> - </item> - - <tag><c>perf_counter</c></tag> - <item><p>Symbolic representation of the performance counter - time unit used by the Erlang runtime system.</p> - - <p>The <c>perf_counter</c> time unit behaves much in the same way - as the <c>native</c> time unit. That is it might differ inbetween - run-time restarts. You get values of this type by calling - <seealso marker="kernel:os#perf_counter/0"><c>os:perf_counter()</c></seealso> - </p> + <tag><c>PartsPerSecond :: integer() >= 1</c></tag> + <item> + <p>Time unit expressed in parts per second. That is, + the time unit equals <c>1/PartsPerSecond</c> second.</p> + </item> + <tag><c>seconds</c></tag> + <item> + <p>Symbolic representation of the time unit + represented by the integer <c>1</c>.</p> + </item> + <tag><c>milli_seconds</c></tag> + <item> + <p>Symbolic representation of the time unit + represented by the integer <c>1000</c>.</p> + </item> + <tag><c>micro_seconds</c></tag> + <item> + <p>Symbolic representation of the time unit + represented by the integer <c>1000000</c>.</p> + </item> + <tag><c>nano_seconds</c></tag> + <item> + <p>Symbolic representation of the time unit + represented by the integer <c>1000000000</c>.</p> + </item> + <tag><c>native</c></tag> + <item> + <p>Symbolic representation of the native time unit + used by the Erlang runtime system.</p> + <p>The <c>native</c> time unit is determined at + runtime system start, and remains the same until + the runtime system terminates. If a runtime system + is stopped and then started again (even on the same + machine), the <c>native</c> time unit of the new + runtime system instance can differ from the + <c>native</c> time unit of the old runtime system + instance.</p> + <p>One can get an approximation of the <c>native</c> + time unit by calling + <seealso marker="erlang:convert_time_unit/3"> + <c>erlang:convert_time_unit(1, seconds, native)</c></seealso>. + The result equals the number + of whole <c>native</c> time units per second. If + the number of <c>native</c> time units per second does not + add up to a whole number, the result is rounded downwards.</p> + <note> + <p>The value of the <c>native</c> time unit gives + you more or less no information about the + quality of time values. It sets a limit for the + <seealso marker="time_correction#Time_Resolution"> + resolution</seealso> and for the + <seealso marker="time_correction#Time_Precision"> + precision</seealso> of time values, + but it gives no information about the + <seealso marker="time_correction#Time_Accuracy"> + accuracy</seealso> of time values. The resolution of + the <c>native</c> time unit and the resolution of time + values can differ significantly.</p> + </note> + </item> + <tag><c>perf_counter</c></tag> + <item> + <p>Symbolic representation of the performance counter + time unit used by the Erlang runtime system.</p> + <p>The <c>perf_counter</c> time unit behaves much in the same way + as the <c>native</c> time unit. That is, it can differ between + runtime restarts. To get values of this type, call + <seealso marker="kernel:os#perf_counter/0"> + <c>os:perf_counter/0</c></seealso>.</p> </item> - - </taglist> - - <p>The <c>time_unit/0</c> type may be extended. Use - <seealso marker="#convert_time_unit/3"><c>erlang:convert_time_unit/3</c></seealso> - in order to convert time values between time units.</p> - + </taglist> + <p>The <c>time_unit/0</c> type can be extended. + To convert time values between time units, use + <seealso marker="#convert_time_unit/3"> + <c>erlang:convert_time_unit/3</c></seealso>.</p> </desc> </datatype> </datatypes> @@ -175,61 +182,60 @@ <func> <name name="adler32" arity="1"/> - <fsummary>Computes adler32 checksum.</fsummary> + <fsummary>Compute adler32 checksum.</fsummary> <desc> <p>Computes and returns the adler32 checksum for - <c><anno>Data</anno></c>.</p> + <c><anno>Data</anno></c>.</p> </desc> </func> <func> <name name="adler32" arity="2"/> - <fsummary>Computes adler32 checksum.</fsummary> + <fsummary>Compute adler32 checksum.</fsummary> <desc> <p>Continues computing the adler32 checksum by combining - the previous checksum, <c><anno>OldAdler</anno></c>, with - the checksum of <c><anno>Data</anno></c>.</p> + the previous checksum, <c><anno>OldAdler</anno></c>, with + the checksum of <c><anno>Data</anno></c>.</p> <p>The following code:</p> <code> - X = erlang:adler32(Data1), - Y = erlang:adler32(X,Data2).</code> - <p>assigns the same value to <c>Y</c> as this:</p> +X = erlang:adler32(Data1), +Y = erlang:adler32(X,Data2).</code> + <p>assigns the same value to <c>Y</c> as this:</p> <code> - Y = erlang:adler32([Data1,Data2]).</code> +Y = erlang:adler32([Data1,Data2]).</code> </desc> </func> <func> <name name="adler32_combine" arity="3"/> - <fsummary>Combines two adler32 checksums.</fsummary> + <fsummary>Combine two adler32 checksums.</fsummary> <desc> <p>Combines two previously computed adler32 checksums. - This computation requires the size of the data object for - the second checksum to be known.</p> + This computation requires the size of the data object for + the second checksum to be known.</p> <p>The following code:</p> <code> - Y = erlang:adler32(Data1), - Z = erlang:adler32(Y,Data2).</code> +Y = erlang:adler32(Data1), +Z = erlang:adler32(Y,Data2).</code> <p>assigns the same value to <c>Z</c> as this:</p> <code> - X = erlang:adler32(Data1), - Y = erlang:adler32(Data2), - Z = erlang:adler32_combine(X,Y,iolist_size(Data2)).</code> +X = erlang:adler32(Data1), +Y = erlang:adler32(Data2), +Z = erlang:adler32_combine(X,Y,iolist_size(Data2)).</code> </desc> </func> <func> <name name="append_element" arity="2"/> - <fsummary>Appends an extra element to a tuple.</fsummary> + <fsummary>Append an extra element to a tuple.</fsummary> <desc> <p>Returns a new tuple that has one element more than <c><anno>Tuple1</anno></c>, and contains the elements in - <c><anno>Tuple1</anno></c> + <c><anno>Tuple1</anno></c> followed by <c><anno>Term</anno></c> as the last element. - Semantically equivalent to + Semantically equivalent to <c>list_to_tuple(tuple_to_list(<anno>Tuple1</anno>) ++ - [<anno>Term</anno>])</c>, but much faster.</p> - <p>Example:</p> + [<anno>Term</anno>])</c>, but much faster. Example:</p> <pre> > <input>erlang:append_element({one, two}, three).</input> {one,two,three}</pre> @@ -238,32 +244,31 @@ <func> <name name="apply" arity="2"/> - <fsummary>Applies a function to an argument list.</fsummary> + <fsummary>Apply a function to an argument list.</fsummary> <desc> <p>Calls a fun, passing the elements in <c><anno>Args</anno></c> - as arguments.</p> + as arguments.</p> <p>If the number of elements in the arguments are known at compile time, the call is better written as <c><anno>Fun</anno>(Arg1, Arg2, ... ArgN)</c>.</p> <warning> - <p>Earlier, <c><anno>Fun</anno></c> could also be given as + <p>Earlier, <c><anno>Fun</anno></c> could also be specified as <c>{Module, Function}</c>, equivalent to - <c>apply(Module, Function, Args)</c>. This use is - deprecated and will stop working in a future release.</p> + <c>apply(Module, Function, Args)</c>. <em>This use is + deprecated and will stop working in a future release.</em></p> </warning> </desc> </func> <func> <name name="apply" arity="3"/> - <fsummary>Applies a function to an argument list.</fsummary> + <fsummary>Apply a function to an argument list.</fsummary> <desc> <p>Returns the result of applying <c>Function</c> in <c><anno>Module</anno></c> to <c><anno>Args</anno></c>. - The applied function must + The applied function must be exported from <c>Module</c>. The arity of the function is - the length of <c>Args</c>.</p> - <p>Example:</p> + the length of <c>Args</c>. Example:</p> <pre> > <input>apply(lists, reverse, [[a, b, c]]).</input> [c,b,a] @@ -271,39 +276,43 @@ "Erlang"</pre> <p>If the number of arguments are known at compile time, the call is better written as - <c><anno>Module</anno>:<anno>Function</anno>(Arg1, Arg2, ..., ArgN)</c>.</p> - <p>Failure: <c>error_handler:undefined_function/3</c> is called + <c><anno>Module</anno>:<anno>Function</anno>(Arg1, Arg2, ..., + ArgN)</c>.</p> + <p>Failure: <seealso marker="kernel:error_handler#undefined_function/3"> + <c>error_handler:undefined_function/3</c></seealso> is called if the applied function is not exported. The error handler can be redefined (see - <seealso marker="#process_flag/2">process_flag/2</seealso>). + <seealso marker="#process_flag/2"><c>process_flag/2</c></seealso>). If <c>error_handler</c> is undefined, or if the user has redefined the default <c>error_handler</c> so the replacement - module is undefined, an error with the reason <c>undef</c> + module is undefined, an error with reason <c>undef</c> is generated.</p> </desc> </func> <func> <name name="atom_to_binary" arity="2"/> - <fsummary>Returns the binary representation of an atom.</fsummary> + <fsummary>Return the binary representation of an atom.</fsummary> <desc> <p>Returns a binary corresponding to the text representation of <c><anno>Atom</anno></c>. If <c><anno>Encoding</anno></c> - is <c>latin1</c>, there is one byte for each character + is <c>latin1</c>, one byte exists for each character in the text representation. If <c><anno>Encoding</anno></c> is <c>utf8</c> or <c>unicode</c>, the characters are encoded using UTF-8 (that is, characters from 128 through 255 are encoded in two bytes).</p> - <note><p><c>atom_to_binary(<anno>Atom</anno>, latin1)</c> never - fails because the text representation of an atom can only - contain characters from 0 through 255. In a future release, - the text representation - of atoms can be allowed to contain any Unicode character and - <c>atom_to_binary(<anno>Atom</anno>, latin1)</c> will then fail if the - text representation for <c><anno>Atom</anno></c> contains a Unicode - character greater than 255.</p></note> + <note> + <p><c>atom_to_binary(<anno>Atom</anno>, latin1)</c> never + fails, as the text representation of an atom can only + contain characters from 0 through 255. In a future release, + the text representation + of atoms can be allowed to contain any Unicode character and + <c>atom_to_binary(<anno>Atom</anno>, latin1)</c> then fails if the + text representation for <c><anno>Atom</anno></c> contains a Unicode + character > 255.</p> + </note> <p>Example:</p> <pre> > <input>atom_to_binary('Erlang', latin1).</input> @@ -325,12 +334,12 @@ <func> <name name="binary_part" arity="2"/> - <fsummary>Extracts a part of a binary.</fsummary> + <fsummary>Extract a part of a binary.</fsummary> <desc> <p>Extracts the part of the binary described by <c><anno>PosLen</anno></c>.</p> <p>Negative length can be used to extract bytes at the end - of a binary, for example:</p> + of a binary, for example:</p> <code> 1> Bin = <<1,2,3,4,5,6,7,8,9,10>>. 2> binary_part(Bin,{byte_size(Bin), -5}). @@ -342,43 +351,44 @@ 1> Bin = <<1,2,3>> 2> binary_part(Bin,{0,2}). <<1,2>></code> - <p>For details about the <c><anno>PosLen</anno></c> semantics, see the - <seealso marker="stdlib:binary">binary</seealso> - manual page in <c>STDLIB</c>.</p> + <p>For details about the <c><anno>PosLen</anno></c> semantics, see + <seealso marker="stdlib:binary"><c>stdlib:binary(3)</c></seealso>.</p> <p>Allowed in guard tests.</p> </desc> </func> <func> <name name="binary_part" arity="3"/> - <fsummary>Extracts a part of a binary.</fsummary> + <fsummary>Extract a part of a binary.</fsummary> <desc> <p>The same as <c>binary_part(<anno>Subject</anno>, - {<anno>Start</anno>, <anno>Length</anno>})</c>.</p> + {<anno>Start</anno>, <anno>Length</anno>})</c>.</p> <p>Allowed in guard tests.</p> </desc> </func> <func> <name name="binary_to_atom" arity="2"/> - <fsummary>Converts from text representation to an atom.</fsummary> + <fsummary>Convert from text representation to an atom.</fsummary> <desc> <p>Returns the atom whose text representation is - <c><anno>Binary</anno></c>. - If <c><anno>Encoding</anno></c> is <c>latin1</c>, no - translation of bytes in the binary is done. - If <c><anno>Encoding</anno></c> - is <c>utf8</c> or <c>unicode</c>, the binary must contain - valid UTF-8 sequences. Only Unicode characters up - to 255 are allowed.</p> - <note><p><c>binary_to_atom(<anno>Binary</anno>, utf8)</c> fails if - the binary contains Unicode characters greater than 255. - In a future release, such Unicode characters can be allowed - and <c>binary_to_atom(<anno>Binary</anno>, utf8)</c> does then not fail. - For more information on Unicode support in atoms, see the - <seealso marker="erl_ext_dist#utf8_atoms">note on UTF-8 - encoded atoms</seealso> - in Section "External Term Format" in the User's Guide.</p></note> + <c><anno>Binary</anno></c>. + If <c><anno>Encoding</anno></c> is <c>latin1</c>, no + translation of bytes in the binary is done. + If <c><anno>Encoding</anno></c> + is <c>utf8</c> or <c>unicode</c>, the binary must contain + valid UTF-8 sequences. Only Unicode characters up + to 255 are allowed.</p> + <note> + <p><c>binary_to_atom(<anno>Binary</anno>, utf8)</c> fails if + the binary contains Unicode characters > 255. + In a future release, such Unicode characters can be allowed and + <c>binary_to_atom(<anno>Binary</anno>, utf8)</c> does then not fail. + For more information about Unicode support in atoms, see the + <seealso marker="erl_ext_dist#utf8_atoms">note on UTF-8 + encoded atoms</seealso> + in section "External Term Format" in the User's Guide.</p> + </note> <p>Examples:</p> <pre> > <input>binary_to_atom(<<"Erlang">>, latin1).</input> @@ -392,10 +402,10 @@ <func> <name name="binary_to_existing_atom" arity="2"/> - <fsummary>Converts from text representation to an atom.</fsummary> + <fsummary>Convert from text representation to an atom.</fsummary> <desc> <p>As - <seealso marker="#binary_to_atom/2">binary_to_atom/2</seealso>, + <seealso marker="#binary_to_atom/2"><c>binary_to_atom/2</c></seealso>, but the atom must exist.</p> <p>Failure: <c>badarg</c> if the atom does not exist.</p> </desc> @@ -403,7 +413,7 @@ <func> <name name="binary_to_float" arity="1"/> - <fsummary>Converts from text representation to a float.</fsummary> + <fsummary>Convert from text representation to a float.</fsummary> <desc> <p>Returns the float whose text representation is <c><anno>Binary</anno></c>, for example:</p> @@ -417,7 +427,7 @@ <func> <name name="binary_to_integer" arity="1"/> - <fsummary>Converts from text representation to an integer.</fsummary> + <fsummary>Convert from text representation to an integer.</fsummary> <desc> <p>Returns an integer whose text representation is <c><anno>Binary</anno></c>, for example:</p> @@ -431,10 +441,11 @@ <func> <name name="binary_to_integer" arity="2"/> - <fsummary>Converts from text representation to an integer.</fsummary> + <fsummary>Convert from text representation to an integer.</fsummary> <desc> <p>Returns an integer whose text representation in base - <c><anno>Base</anno></c> is <c><anno>Binary</anno></c>, for example:</p> + <c><anno>Base</anno></c> is <c><anno>Binary</anno></c>, for + example:</p> <pre> > <input>binary_to_integer(<<"3FF">>, 16).</input> 1023</pre> @@ -445,7 +456,7 @@ <func> <name name="binary_to_list" arity="1"/> - <fsummary>Converts a binary to a list.</fsummary> + <fsummary>Convert a binary to a list.</fsummary> <desc> <p>Returns a list of integers corresponding to the bytes of <c><anno>Binary</anno></c>.</p> @@ -454,86 +465,83 @@ <func> <name name="binary_to_list" arity="3"/> - <fsummary>Converts part of a binary to a list.</fsummary> - <type_desc variable="Start">1..byte_size(<c><anno>Binary</anno></c>)</type_desc> + <fsummary>Convert part of a binary to a list.</fsummary> + <type_desc variable="Start">1..byte_size(<c><anno>Binary</anno></c>) + </type_desc> <desc> <p>As <c>binary_to_list/1</c>, but returns a list of integers corresponding to the bytes from position <c><anno>Start</anno></c> to position <c><anno>Stop</anno></c> in <c><anno>Binary</anno></c>. - The positions in the + The positions in the binary are numbered starting from 1.</p> - <note><p>The one-based indexing for binaries used by - this function is deprecated. New code is to use - <seealso marker="stdlib:binary#bin_to_list/3">binary:bin_to_list/3</seealso> - in <c>STDLIB</c> instead. All functions in module - <c>binary</c> consistently use zero-based indexing.</p></note> - </desc> - </func> - - <func> - <name name="bitstring_to_list" arity="1"/> - <fsummary>Converts a bitstring to a list.</fsummary> - <desc> - <p>Returns a list of integers corresponding to the bytes of - <c><anno>Bitstring</anno></c>. If the number of bits in the binary - is not divisible by 8, the last element of the list is a bitstring - containing the remaining 1-7 bits.</p> + <note> + <p><em>The one-based indexing for binaries used by + this function is deprecated.</em> New code is to use + <seealso marker="stdlib:binary#bin_to_list/3"> + <c>binary:bin_to_list/3</c></seealso> + in <c>STDLIB</c> instead. All functions in module + <c>binary</c> consistently use zero-based indexing.</p> + </note> </desc> </func> <func> <name name="binary_to_term" arity="1"/> - <fsummary>Decodes an Erlang external term format binary.</fsummary> + <fsummary>Decode an Erlang external term format binary.</fsummary> <desc> <p>Returns an Erlang term that is the result of decoding binary object <c><anno>Binary</anno></c>, which must be encoded according to the Erlang external term format.</p> - <warning><p>When decoding binaries from untrusted sources, - consider using <c>binary_to_term/2</c> to prevent Denial - of Service attacks.</p></warning> + <warning> + <p>When decoding binaries from untrusted sources, + consider using <c>binary_to_term/2</c> to prevent Denial + of Service attacks.</p> + </warning> <p>See also - <seealso marker="#term_to_binary/1">term_to_binary/1</seealso> - and - <seealso marker="#binary_to_term/2">binary_to_term/2</seealso>.</p> + <seealso marker="#term_to_binary/1"><c>term_to_binary/1</c></seealso> + and <seealso marker="#binary_to_term/2"> + <c>binary_to_term/2</c></seealso>.</p> </desc> </func> <func> <name name="binary_to_term" arity="2"/> - <fsummary>Decodes an Erlang external term format binary.</fsummary> + <fsummary>Decode an Erlang external term format binary.</fsummary> <desc> <p>As <c>binary_to_term/1</c>, but takes options that affect decoding - of the binary.</p> + of the binary.</p> + <p>Option:</p> <taglist> <tag><c>safe</c></tag> <item> <p>Use this option when receiving binaries from an untrusted - source.</p> + source.</p> <p>When enabled, it prevents decoding data that can be used to - attack the Erlang system. In the event of receiving unsafe - data, decoding fails with a <c>badarg</c> error.</p> + attack the Erlang system. In the event of receiving unsafe + data, decoding fails with a <c>badarg</c> error.</p> <p>This prevents creation of new atoms directly, - creation of new atoms indirectly (as they are embedded in - certain structures, such as process identifiers, - refs, and funs), and - creation of new external function references. - None of those resources are garbage collected, so unchecked - creation of them can exhaust available memory.</p> + creation of new atoms indirectly (as they are embedded in + certain structures, such as process identifiers, + refs, and funs), and + creation of new external function references. + None of those resources are garbage collected, so unchecked + creation of them can exhaust available memory.</p> </item> </taglist> <p>Failure: <c>badarg</c> if <c>safe</c> is specified and unsafe - data is decoded.</p> + data is decoded.</p> <p>See also - <seealso marker="#term_to_binary/1">term_to_binary/1</seealso>, - <seealso marker="#binary_to_term/1">binary_to_term/1</seealso>, - and - <seealso marker="#list_to_existing_atom/1">list_to_existing_atom/1</seealso>.</p> + <seealso marker="#term_to_binary/1"><c>term_to_binary/1</c></seealso>, + <seealso marker="#binary_to_term/1"> + <c>binary_to_term/1</c></seealso>, and + <seealso marker="#list_to_existing_atom/1"> + <c>list_to_existing_atom/1</c></seealso>.</p> </desc> </func> <func> <name name="bit_size" arity="1"/> - <fsummary>Returns the size of a bitstring.</fsummary> + <fsummary>Return the size of a bitstring.</fsummary> <desc> <p>Returns an integer that is the size in bits of <c><anno>Bitstring</anno></c>, for example:</p> @@ -547,15 +555,26 @@ </func> <func> + <name name="bitstring_to_list" arity="1"/> + <fsummary>Convert a bitstring to a list.</fsummary> + <desc> + <p>Returns a list of integers corresponding to the bytes of + <c><anno>Bitstring</anno></c>. If the number of bits in the binary + is not divisible by 8, the last element of the list is a bitstring + containing the remaining 1-7 bits.</p> + </desc> + </func> + + <func> <name name="bump_reductions" arity="1"/> - <fsummary>Increments the reduction counter.</fsummary> + <fsummary>Increment the reduction counter.</fsummary> <desc> <p>This implementation-dependent function increments the reduction counter for the calling process. In the Beam emulator, the reduction counter is normally incremented by one for each function and BIF call. A context switch is forced when the counter reaches the maximum number of - reductions for a process (2000 reductions in OTP R12B).</p> + reductions for a process (2000 reductions in Erlang/OTP R12B).</p> <warning> <p>This BIF can be removed in a future version of the Beam machine without prior warning. It is unlikely to be @@ -566,13 +585,12 @@ <func> <name name="byte_size" arity="1"/> - <fsummary>Returns the size of a bitstring (or binary).</fsummary> + <fsummary>Return the size of a bitstring (or binary).</fsummary> <desc> <p>Returns an integer that is the number of bytes needed to contain <c><anno>Bitstring</anno></c>. That is, if the number of bits in <c><anno>Bitstring</anno></c> is not divisible by 8, the resulting - number of bytes is rounded <em>up</em>.</p> - <p>Examples:</p> + number of bytes is rounded <em>up</em>. Examples:</p> <pre> > <input>byte_size(<<433:16,3:3>>).</input> 3 @@ -583,134 +601,127 @@ </func> <func> - <name name="cancel_timer" arity="2"/> - <fsummary>Cancels a timer.</fsummary> + <name name="cancel_timer" arity="1"/> + <fsummary>Cancel a timer.</fsummary> <desc> - <p> - Cancels a timer that has been created by - <seealso marker="#start_timer/4"><c>erlang:start_timer()</c></seealso>, - or <seealso marker="#send_after/4"><c>erlang:send_after()</c></seealso>. - <c><anno>TimerRef</anno></c> identifies the timer, and - was returned by the BIF that created the timer. - </p> - <p>Available <c><anno>Option</anno></c>s:</p> + <p>Cancels a timer. The same as calling + <seealso marker="#cancel_timer/2"> + <c>erlang:cancel_timer(TimerRef, [])</c></seealso>.</p> + </desc> + </func> + + <func> + <name name="cancel_timer" arity="2"/> + <fsummary>Cancel a timer.</fsummary> + <desc> + <p>Cancels a timer that has been created by + <seealso marker="#start_timer/4"> + <c>erlang:start_timer</c></seealso> or + <seealso marker="#send_after/4"><c>erlang:send_after</c></seealso>. + <c><anno>TimerRef</anno></c> identifies the timer, and + was returned by the BIF that created the timer.</p> + <p><c><anno>Option</anno></c>s:</p> <taglist> <tag><c>{async, Async}</c></tag> <item> - <p> - Asynchronous request for cancellation. <c>Async</c> - defaults to <c>false</c> which will cause the - cancellation to be performed synchronously. When - <c>Async</c> is set to <c>true</c>, the cancel - operation is performed asynchronously. That is, - <c>erlang:cancel_timer()</c> will send an asynchronous - request for cancellation to the timer service that - manages the timer, and then return <c>ok</c>. - </p> - </item> + <p>Asynchronous request for cancellation. <c>Async</c> + defaults to <c>false</c>, which causes the + cancellation to be performed synchronously. When + <c>Async</c> is set to <c>true</c>, the cancel + operation is performed asynchronously. That is, + <c>cancel_timer()</c> sends an asynchronous + request for cancellation to the timer service that + manages the timer, and then returns <c>ok</c>.</p> + </item> <tag><c>{info, Info}</c></tag> <item> - <p> - Request information about the <c><anno>Result</anno></c> - of the cancellation. <c>Info</c> defaults to <c>true</c> - which means the <c><anno>Result</anno></c> is - given. When <c>Info</c> is set to <c>false</c>, no - information about the result of the cancellation - is given. When the operation is performed</p> - <taglist> - <tag>synchronously</tag> - <item> - <p> - If <c>Info</c> is <c>true</c>, the <c>Result</c> is - returned by <c>erlang:cancel_timer()</c>; otherwise, - <c>ok</c> is returned. - </p> - </item> - <tag>asynchronously</tag> - <item> - <p> - If <c>Info</c> is <c>true</c>, a message on the form - <c>{cancel_timer, <anno>TimerRef</anno>, - <anno>Result</anno>}</c> is sent to the - caller of <c>erlang:cancel_timer()</c> when the - cancellation operation has been performed; otherwise, - no message is sent. - </p> - </item> - </taglist> - </item> - </taglist> - <p> - More <c><anno>Option</anno></c>s may be added in the future. - </p> - <p>If <c><anno>Result</anno></c> is an integer, it represents - the time in milli-seconds left until the canceled timer would - have expired.</p> - <p> - If <c><anno>Result</anno></c> is <c>false</c>, a - timer corresponding to <c><anno>TimerRef</anno></c> could not - be found. This can be either because the timer had expired, - already had been canceled, or because <c><anno>TimerRef</anno></c> - never corresponded to a timer. Even if the timer had expired, - it does not tell you whether or not the timeout message has - arrived at its destination yet. - </p> - <note> - <p> - The timer service that manages the timer may be co-located - with another scheduler than the scheduler that the calling - process is executing on. If this is the case, communication - with the timer service takes much longer time than if it - is located locally. If the calling process is in critical - path, and can do other things while waiting for the result - of this operation, or is not interested in the result of - the operation, you want to use option <c>{async, true}</c>. - If using option <c>{async, false}</c>, the calling - process blocks until the operation has been performed. - </p> - </note> - <p>See also + <p>Requests information about the <c><anno>Result</anno></c> + of the cancellation. <c>Info</c> defaults to <c>true</c>, + which means the <c><anno>Result</anno></c> is + given. When <c>Info</c> is set to <c>false</c>, no + information about the result of the cancellation + is given.</p> + <list type="bulleted"> + <item> + <p>When <c>Async</c> is <c>false</c>: + if <c>Info</c> is <c>true</c>, the <c>Result</c> is + returned by <c>erlang:cancel_timer()</c>. otherwise + <c>ok</c> is returned.</p> + </item> + <item> + <p>When <c>Async</c> is <c>true</c>: + if <c>Info</c> is <c>true</c>, a message on the form + <c>{cancel_timer, <anno>TimerRef</anno>, + <anno>Result</anno>}</c> is sent to the + caller of <c>erlang:cancel_timer()</c> when the + cancellation operation has been performed, otherwise + no message is sent.</p> + </item> + </list> + </item> + </taglist> + <p>More <c><anno>Option</anno></c>s may be added in the future.</p> + <p>If <c><anno>Result</anno></c> is an integer, it represents + the time in milliseconds left until the canceled timer would + have expired.</p> + <p>If <c><anno>Result</anno></c> is <c>false</c>, a + timer corresponding to <c><anno>TimerRef</anno></c> could not + be found. This can be either because the timer had expired, + already had been canceled, or because <c><anno>TimerRef</anno></c> + never corresponded to a timer. Even if the timer had expired, + it does not tell you if the time-out message has + arrived at its destination yet.</p> + <note> + <p>The timer service that manages the timer can be co-located + with another scheduler than the scheduler that the calling + process is executing on. If so, communication + with the timer service takes much longer time than if it + is located locally. If the calling process is in critical + path, and can do other things while waiting for the result + of this operation, or is not interested in the result of + the operation, you want to use option <c>{async, true}</c>. + If using option <c>{async, false}</c>, the calling + process blocks until the operation has been performed.</p> + </note> + <p>See also <seealso marker="#send_after/4"><c>erlang:send_after/4</c></seealso>, - <seealso marker="#start_timer/4"><c>erlang:start_timer/4</c></seealso>, - and - <seealso marker="#read_timer/2"><c>erlang:read_timer/2</c></seealso>.</p> - </desc> - </func> - <func> - <name name="cancel_timer" arity="1"/> - <fsummary>Cancels a timer.</fsummary> - <desc> - <p>Cancels a timer. The same as calling - <seealso marker="#cancel_timer/2"><c>erlang:cancel_timer(TimerRef, - [])</c></seealso>.</p> + <seealso marker="#start_timer/4"> + <c>erlang:start_timer/4</c></seealso>, and + <seealso marker="#read_timer/2"> + <c>erlang:read_timer/2</c></seealso>.</p> </desc> </func> + <func> <name name="check_old_code" arity="1"/> - <fsummary>Checks if a module has old code.</fsummary> + <fsummary>Check if a module has old code.</fsummary> <desc> <p>Returns <c>true</c> if <c><anno>Module</anno></c> has old code, - otherwise <c>false</c>.</p> - <p>See also <seealso marker="kernel:code">code(3)</seealso>.</p> + otherwise <c>false</c>.</p> + <p>See also <seealso marker="kernel:code"> + <c>kernel:code(3)</c></seealso>.</p> </desc> </func> <func> <name name="check_process_code" arity="2"/> - <fsummary>Checks if a process executes old code for a module.</fsummary> + <fsummary>Check if a process executes old code for a module.</fsummary> <desc> <p>The same as - <seealso marker="#check_process_code/3"><c>erlang:check_process_code(<anno>Pid</anno>, <anno>Module</anno>, [])</c></seealso>.</p> + <seealso marker="#check_process_code/3"> + <c>check_process_code(<anno>Pid</anno>, <anno>Module</anno>, [])</c> + </seealso>.</p> </desc> </func> <func> <name name="check_process_code" arity="3"/> - <fsummary>Checks if a process executes old code for a module.</fsummary> + <fsummary>Check if a process executes old code for a module.</fsummary> <desc> - <p>Checks if the node local process identified by <c><anno>Pid</anno></c> - executes old code for <c><anno>Module</anno></c>.</p> - <p>The available <c><anno>Option</anno></c>s are as follows:</p> + <p>Checks if the node local process identified by + <c><anno>Pid</anno></c> + executes old code for <c><anno>Module</anno></c>.</p> + <p><c><anno>Option</anno></c>s:</p> <taglist> <tag><c>{allow_gc, boolean()}</c></tag> <item> @@ -718,30 +729,30 @@ the operation. If <c>{allow_gc, false}</c> is passed, and a garbage collection is needed to determine the result of the operation, the operation is aborted (see - information on <c><anno>CheckResult</anno></c> in the following). + information on <c><anno>CheckResult</anno></c> below). The default is to allow garbage collection, that is, <c>{allow_gc, true}</c>.</p> - </item> + </item> <tag><c>{async, RequestId}</c></tag> <item> <p>The function <c>check_process_code/3</c> returns the value <c>async</c> immediately after the request has been sent. When the request has been processed, the process that called this function is passed a - message on the form - <c>{check_process_code, <anno>RequestId</anno>, <anno>CheckResult</anno>}</c>.</p> - </item> + message on the form <c>{check_process_code, <anno>RequestId</anno>, + <anno>CheckResult</anno>}</c>.</p> + </item> </taglist> <p>If <c><anno>Pid</anno></c> equals <c>self()</c>, and - no <c>async</c> option has been passed, the operation - is performed at once. Otherwise a request for - the operation is sent to the process identified by - <c><anno>Pid</anno></c>, and is handled when - appropriate. If no <c>async</c> option has been passed, - the caller blocks until <c><anno>CheckResult</anno></c> - is available and can be returned.</p> + no <c>async</c> option has been passed, the operation + is performed at once. Otherwise a request for + the operation is sent to the process identified by + <c><anno>Pid</anno></c>, and is handled when + appropriate. If no <c>async</c> option has been passed, + the caller blocks until <c><anno>CheckResult</anno></c> + is available and can be returned.</p> <p><c><anno>CheckResult</anno></c> informs about the result of - the request as follows:</p> + the request as follows:</p> <taglist> <tag><c>true</c></tag> <item> @@ -751,54 +762,82 @@ code for this module, or the process has references to old code for this module, or the process contains funs that references old code for this module.</p> - </item> + </item> <tag><c>false</c></tag> <item> <p>The process identified by <c><anno>Pid</anno></c> does not execute old code for <c><anno>Module</anno></c>.</p> - </item> + </item> <tag><c>aborted</c></tag> <item> <p>The operation was aborted, as the process needed to be garbage collected to determine the operation result, and the operation was requested - by passing option <c>{allow_gc, false}</c>.</p></item> + by passing option <c>{allow_gc, false}</c>.</p> + </item> </taglist> - <p>See also <seealso marker="kernel:code">code(3)</seealso>.</p> + <note> + <p> + Up until ERTS version 8.*, the check process code operation + checks for all types of references to the old code. That is, + direct references (e.g. return addresses on the process + stack), indirect references (<c>fun</c>s in process + context), and references to literals in the code. + </p> + <p> + As of ERTS version 9.0, the check process code operation + only checks for direct references to the code. Indirect + references via <c>fun</c>s will be ignored. If such + <c>fun</c>s exist and are used after a purge of the old + code, an exception will be raised upon usage (same as + the case when the <c>fun</c> is received by the process + after the purge). Literals will be taken care of (copied) + at a later stage. This behavior can as of ERTS version + 8.1 be enabled when + <seealso marker="doc/installation_guide:INSTALL#Advanced-configuration-and-build-of-ErlangOTP_Configuring">building OTP</seealso>, + and will automatically be enabled if dirty scheduler + support is enabled. + </p> + </note> + <p>See also <seealso marker="kernel:code"> + <c>kernel:code(3)</c></seealso>.</p> <p>Failures:</p> <taglist> <tag><c>badarg</c></tag> - <item>If <c><anno>Pid</anno></c> is not a node local process identifier. - </item> + <item>If <c><anno>Pid</anno></c> is not a node local process + identifier. + </item> <tag><c>badarg</c></tag> <item>If <c><anno>Module</anno></c> is not an atom. - </item> + </item> <tag><c>badarg</c></tag> <item>If <c><anno>OptionList</anno></c> is an invalid list of options. - </item> + </item> </taglist> </desc> </func> <func> <name name="convert_time_unit" arity="3"/> - <fsummary>Converts time unit of a time value.</fsummary> + <fsummary>Convert time unit of a time value.</fsummary> <desc> - <p>Converts the <c><anno>Time</anno></c> value of time unit - <c><anno>FromUnit</anno></c> to the corresponding - <c><anno>ConvertedTime</anno></c> value of time unit - <c><anno>ToUnit</anno></c>. The result is rounded - using the floor function.</p> - - <warning><p>You may lose accuracy and precision when converting - between time units. In order to minimize such loss, collect all - data at <c>native</c> time unit and do the conversion on the end - result.</p></warning> + <p>Converts the <c><anno>Time</anno></c> value of time unit + <c><anno>FromUnit</anno></c> to the corresponding + <c><anno>ConvertedTime</anno></c> value of time unit + <c><anno>ToUnit</anno></c>. The result is rounded + using the floor function.</p> + <warning> + <p>You can lose accuracy and precision when converting + between time units. To minimize such loss, collect all + data at <c>native</c> time unit and do the conversion on the end + result.</p> + </warning> </desc> </func> + <func> <name name="crc32" arity="1"/> - <fsummary>Computes crc32 (IEEE 802.3) checksum.</fsummary> + <fsummary>Compute crc32 (IEEE 802.3) checksum.</fsummary> <desc> <p>Computes and returns the crc32 (IEEE 802.3 style) checksum for <c><anno>Data</anno></c>.</p> @@ -807,37 +846,37 @@ <func> <name name="crc32" arity="2"/> - <fsummary>Computes crc32 (IEEE 802.3) checksum.</fsummary> + <fsummary>Compute crc32 (IEEE 802.3) checksum.</fsummary> <desc> <p>Continues computing the crc32 checksum by combining - the previous checksum, <c><anno>OldCrc</anno></c>, with the checksum of - <c><anno>Data</anno></c>.</p> + the previous checksum, <c><anno>OldCrc</anno></c>, with the checksum + of <c><anno>Data</anno></c>.</p> <p>The following code:</p> <code> - X = erlang:crc32(Data1), - Y = erlang:crc32(X,Data2).</code> +X = erlang:crc32(Data1), +Y = erlang:crc32(X,Data2).</code> <p>assigns the same value to <c>Y</c> as this:</p> <code> - Y = erlang:crc32([Data1,Data2]).</code> +Y = erlang:crc32([Data1,Data2]).</code> </desc> </func> <func> <name name="crc32_combine" arity="3"/> - <fsummary>Combines two crc32 (IEEE 802.3) checksums.</fsummary> + <fsummary>Combine two crc32 (IEEE 802.3) checksums.</fsummary> <desc> <p>Combines two previously computed crc32 checksums. - This computation requires the size of the data object for - the second checksum to be known.</p> + This computation requires the size of the data object for + the second checksum to be known.</p> <p>The following code:</p> <code> - Y = erlang:crc32(Data1), - Z = erlang:crc32(Y,Data2).</code> +Y = erlang:crc32(Data1), +Z = erlang:crc32(Y,Data2).</code> <p>assigns the same value to <c>Z</c> as this:</p> <code> - X = erlang:crc32(Data1), - Y = erlang:crc32(Data2), - Z = erlang:crc32_combine(X,Y,iolist_size(Data2)).</code> +X = erlang:crc32(Data1), +Y = erlang:crc32(Data2), +Z = erlang:crc32_combine(X,Y,iolist_size(Data2)).</code> </desc> </func> @@ -847,8 +886,7 @@ <desc> <p>Returns the current date as <c>{Year, Month, Day}</c>.</p> <p>The time zone and Daylight Saving Time correction depend on - the underlying OS.</p> - <p>Example:</p> + the underlying OS. Example:</p> <pre> > <input>date().</input> {1995,2,19}</pre> @@ -857,28 +895,29 @@ <func> <name name="decode_packet" arity="3"/> - <fsummary>Extracts a protocol packet from a binary.</fsummary> + <fsummary>Extract a protocol packet from a binary.</fsummary> <desc> <p>Decodes the binary <c><anno>Bin</anno></c> according to the packet - protocol specified by <c><anno>Type</anno></c>. Similar to the packet - handling done by sockets with option {packet,<anno>Type</anno>}.</p> + protocol specified by <c><anno>Type</anno></c>. Similar to the packet + handling done by sockets with option + <c>{packet,<anno>Type</anno>}.</c></p> <p>If an entire packet is contained in <c><anno>Bin</anno></c>, it is - returned together with the remainder of the binary as - <c>{ok,<anno>Packet</anno>,<anno>Rest</anno>}</c>.</p> + returned together with the remainder of the binary as + <c>{ok,<anno>Packet</anno>,<anno>Rest</anno>}</c>.</p> <p>If <c><anno>Bin</anno></c> does not contain the entire packet, - <c>{more,<anno>Length</anno>}</c> is returned. - <c><anno>Length</anno></c> is either the - expected <em>total size</em> of the packet, or <c>undefined</c> - if the expected packet size is unknown. <c>decode_packet</c> - can then be called again with more data added.</p> + <c>{more,<anno>Length</anno>}</c> is returned. + <c><anno>Length</anno></c> is either the + expected <em>total size</em> of the packet, or <c>undefined</c> + if the expected packet size is unknown. <c>decode_packet</c> + can then be called again with more data added.</p> <p>If the packet does not conform to the protocol format, - <c>{error,<anno>Reason</anno>}</c> is returned.</p> - <p>The following <c>Type</c>s are valid:</p> + <c>{error,<anno>Reason</anno>}</c> is returned.</p> + <p><c>Type</c>s:</p> <taglist> <tag><c>raw | 0</c></tag> <item> <p>No packet handling is done. The entire binary is - returned unless it is empty.</p> + returned unless it is empty.</p> </item> <tag><c>1 | 2 | 4</c></tag> <item> @@ -890,10 +929,10 @@ </item> <tag><c>line</c></tag> <item> - <p>A packet is a line terminated by a delimiter byte, - default is the latin1 newline character. The delimiter - byte is included in the returned packet unless the line - was truncated according to option <c>line_length</c>.</p> + <p>A packet is a line-terminated by a delimiter byte, + default is the latin-1 newline character. The delimiter + byte is included in the returned packet unless the line + was truncated according to option <c>line_length</c>.</p> </item> <tag><c>asn1 | cdr | sunrm | fcgi | tpkt</c></tag> <item> @@ -910,50 +949,51 @@ <tag><c>http | httph | http_bin | httph_bin</c></tag> <item> <p>The Hypertext Transfer Protocol. The packets - are returned with the format according to - <c><anno>HttpPacket</anno></c> described earlier. - A packet is either a - request, a response, a header, or an end of header - mark. Invalid lines are returned as - <c><anno>HttpError</anno></c>.</p> + are returned with the format according to + <c><anno>HttpPacket</anno></c> described earlier. + A packet is either a + request, a response, a header, or an end of header + mark. Invalid lines are returned as + <c><anno>HttpError</anno></c>.</p> <p>Recognized request methods and header fields are returned - as atoms. Others are returned as strings. Strings of - unrecognized header fields are formatted with only - capital letters first and after hyphen characters, for - example, <c>"Sec-Websocket-Key"</c>.</p> + as atoms. Others are returned as strings. Strings of + unrecognized header fields are formatted with only + capital letters first and after hyphen characters, for + example, <c>"Sec-Websocket-Key"</c>.</p> <p>The protocol type <c>http</c> is only to be used for - the first line when an <c><anno>HttpRequest</anno></c> or an - <c><anno>HttpResponse</anno></c> is expected. - The following calls are to use <c>httph</c> to get - <c><anno>HttpHeader</anno></c>s until - <c>http_eoh</c> is returned, which marks the end of the - headers and the beginning of any following message body.</p> + the first line when an <c><anno>HttpRequest</anno></c> or an + <c><anno>HttpResponse</anno></c> is expected. + The following calls are to use <c>httph</c> to get + <c><anno>HttpHeader</anno></c>s until + <c>http_eoh</c> is returned, which marks the end of the + headers and the beginning of any following message body.</p> <p>The variants <c>http_bin</c> and <c>httph_bin</c> return - strings (<c>HttpString</c>) as binaries instead of lists.</p> + strings (<c>HttpString</c>) as binaries instead of lists.</p> </item> </taglist> - <p>The following options are available:</p> - <taglist> - <tag><c>{packet_size, integer() >= 0}</c></tag> - <item><p>Sets the maximum allowed size of the packet body. - If the packet header indicates that the length of the - packet is longer than the maximum allowed length, the - packet is considered invalid. Default is 0, which means - no size limit.</p> - </item> - <tag><c>{line_length, integer() >= 0}</c></tag> - <item><p>For packet type <c>line</c>, lines longer than + <p>Options:</p> + <taglist> + <tag><c>{packet_size, integer() >= 0}</c></tag> + <item><p>Sets the maximum allowed size of the packet body. + If the packet header indicates that the length of the + packet is longer than the maximum allowed length, the + packet is considered invalid. Defaults to 0, which means + no size limit.</p> + </item> + <tag><c>{line_length, integer() >= 0}</c></tag> + <item> + <p>For packet type <c>line</c>, lines longer than the indicated length are truncated.</p> - <p>Option <c>line_length</c> also applies to <c>http*</c> - packet types as an alias for option <c>packet_size</c> - if <c>packet_size</c> itself is not set. This use is - only intended for backward compatibility.</p> - </item> - <tag><c>{line_delimiter, 0 =< byte() =< 255}</c></tag> - <item><p>For packet type <c>line</c>, sets the delimiting byte. - Default is the latin1 character <c>$\n</c>.</p> - </item> - </taglist> + <p>Option <c>line_length</c> also applies to <c>http*</c> + packet types as an alias for option <c>packet_size</c> + if <c>packet_size</c> itself is not set. This use is + only intended for backward compatibility.</p> + </item> + <tag><c>{line_delimiter, 0 =< byte() =< 255}</c></tag> + <item><p>For packet type <c>line</c>, sets the delimiting byte. + Default is the latin-1 character <c>$\n</c>.</p> + </item> + </taglist> <p>Examples:</p> <pre> > <input>erlang:decode_packet(1,<<3,"abcd">>,[]).</input> @@ -965,7 +1005,7 @@ <func> <name name="delete_element" arity="2"/> - <fsummary>Deletes element at index in a tuple.</fsummary> + <fsummary>Delete element at index in a tuple.</fsummary> <type_desc variable="Index">1..tuple_size(<anno>Tuple1</anno>)</type_desc> <desc> <p>Returns a new tuple with element at <c><anno>Index</anno></c> @@ -978,16 +1018,16 @@ <func> <name name="delete_module" arity="1"/> - <fsummary>Makes the current code for a module old.</fsummary> + <fsummary>Make the current code for a module old.</fsummary> <desc> - <p>Makes the current code for <c><anno>Module</anno></c> become old code, - and deletes all references for this module from the export table. + <p>Makes the current code for <c><anno>Module</anno></c> become old + code and deletes all references for this module from the export table. Returns <c>undefined</c> if the module does not exist, otherwise <c>true</c>.</p> <warning> <p>This BIF is intended for the code server (see - <seealso marker="kernel:code">code(3)</seealso>) and is not - to be used elsewhere.</p> + <seealso marker="kernel:code"><c>kernel:code(3)</c></seealso>) + and is not to be used elsewhere.</p> </warning> <p>Failure: <c>badarg</c> if there already is an old version of <c>Module</c>.</p> @@ -996,54 +1036,56 @@ <func> <name name="demonitor" arity="1"/> - <fsummary>Stops monitoring.</fsummary> + <fsummary>Stop monitoring.</fsummary> <desc> <p>If <c><anno>MonitorRef</anno></c> is a reference that the calling process obtained by calling - <seealso marker="#monitor/2">monitor/2</seealso>, + <seealso marker="#monitor/2"><c>monitor/2</c></seealso>, this monitoring is turned off. If the monitoring is already turned off, nothing happens.</p> <p>Once <c>demonitor(<anno>MonitorRef</anno>)</c> has returned, it is guaranteed that no <c>{'DOWN', <anno>MonitorRef</anno>, _, _, _}</c> message, because of the monitor, will be placed in the caller message queue - in the future. A <c>{'DOWN', + in the future. However, a <c>{'DOWN', <anno>MonitorRef</anno>, _, _, _}</c> message can have been placed in the caller message queue before - the call, though. It is therefore usually advisable + the call. It is therefore usually advisable to remove such a <c>'DOWN'</c> message from the message queue after monitoring has been stopped. - <seealso marker="#demonitor/2"><c>demonitor(<anno>MonitorRef</anno>, [flush])</c></seealso> - can be used instead of - <c>demonitor(<anno>MonitorRef</anno>)</c> if this cleanup is wanted.</p> + <seealso marker="#demonitor/2"> + <c>demonitor(<anno>MonitorRef</anno>, [flush])</c></seealso> + can be used instead of <c>demonitor(<anno>MonitorRef</anno>)</c> + if this cleanup is wanted.</p> <note> - <p>Prior to OTP release R11B (ERTS version 5.5) <c>demonitor/1</c> - behaved completely asynchronously, i.e., the monitor was active + <p>Before Erlang/OTP R11B (ERTS 5.5) <c>demonitor/1</c> + behaved completely asynchronously, that is, the monitor was active until the "demonitor signal" reached the monitored entity. This had one undesirable effect. You could never know when you were guaranteed <em>not</em> to receive a <c>DOWN</c> message - due to the monitor.</p> - <p>Current behavior can be viewed as two combined operations: + because of the monitor.</p> + <p>The current behavior can be viewed as two combined operations: asynchronously send a "demonitor signal" to the monitored entity - and ignore any future results of the monitor. </p> + and ignore any future results of the monitor.</p> </note> <p>Failure: It is an error if <c><anno>MonitorRef</anno></c> refers to a monitoring started by another process. Not all such cases are cheap to check. If checking is cheap, the call fails with - <c>badarg</c> for example, if <c><anno>MonitorRef</anno></c> is a + <c>badarg</c>, for example if <c><anno>MonitorRef</anno></c> is a remote reference.</p> </desc> </func> <func> <name name="demonitor" arity="2"/> - <fsummary>Stops monitoring.</fsummary> + <fsummary>Stop monitoring.</fsummary> <desc> <p>The returned value is <c>true</c> unless <c>info</c> is part of <c><anno>OptionList</anno></c>.</p> <p><c>demonitor(<anno>MonitorRef</anno>, [])</c> is equivalent to - <seealso marker="#demonitor/1"><c>demonitor(<anno>MonitorRef</anno>)</c></seealso>.</p> - <p>The available <c><anno>Option</anno></c>s are as follows:</p> + <seealso marker="#demonitor/1"> + <c>demonitor(<anno>MonitorRef</anno>)</c></seealso>.</p> + <p><c><anno>Option</anno></c>s:</p> <taglist> <tag><c>flush</c></tag> <item> @@ -1054,28 +1096,28 @@ <p>Calling <c>demonitor(<anno>MonitorRef</anno>, [flush])</c> is equivalent to the following, but more efficient:</p> <code type="none"> - demonitor(MonitorRef), - receive - {_, MonitorRef, _, _, _} -> - true - after 0 -> - true - end</code> +demonitor(MonitorRef), +receive + {_, MonitorRef, _, _, _} -> + true +after 0 -> + true +end</code> </item> <tag><c>info</c></tag> <item> <p>The returned value is one of the following:</p> <taglist> <tag><c>true</c></tag> - <item>The monitor was found and removed. In this case, + <item><p>The monitor was found and removed. In this case, no <c>'DOWN'</c> message corresponding to this - monitor has been delivered and will not be delivered. + monitor has been delivered and will not be delivered.</p> </item> <tag><c>false</c></tag> - <item>The monitor was not found and could not be removed. + <item><p>The monitor was not found and could not be removed. This probably because someone already has placed a <c>'DOWN'</c> message corresponding to this monitor - in the caller message queue. + in the caller message queue.</p> </item> </taglist> <p>If option <c>info</c> is combined with option <c>flush</c>, @@ -1090,21 +1132,21 @@ <taglist> <tag><c>badarg</c></tag> <item>If <c><anno>OptionList</anno></c> is not a list. - </item> + </item> <tag><c>badarg</c></tag> <item>If <c><anno>Option</anno></c> is an invalid option. - </item> + </item> <tag><c>badarg</c></tag> <item>The same failure as for - <seealso marker="#demonitor/1">demonitor/1</seealso>. - </item> + <seealso marker="#demonitor/1"><c>demonitor/1</c></seealso>. + </item> </taglist> </desc> </func> <func> <name name="disconnect_node" arity="1"/> - <fsummary>Forces the disconnection of a node.</fsummary> + <fsummary>Force the disconnection of a node.</fsummary> <desc> <p>Forces the disconnection of a node. This appears to the node <c><anno>Node</anno></c> as if the local node has crashed. @@ -1118,7 +1160,7 @@ <func> <name name="display" arity="1"/> - <fsummary>Prints a term on standard output.</fsummary> + <fsummary>Print a term on standard output.</fsummary> <desc> <p>Prints a text representation of <c><anno>Term</anno></c> on the standard output.</p> @@ -1130,7 +1172,7 @@ <func> <name name="element" arity="2"/> - <fsummary>Returns the Nth element of a tuple.</fsummary> + <fsummary>Return the Nth element of a tuple.</fsummary> <type_desc variable="N">1..tuple_size(<anno>Tuple</anno>)</type_desc> <desc> <p>Returns the <c><anno>N</anno></c>th element (numbering from 1) of @@ -1144,7 +1186,7 @@ b</pre> <func> <name name="erase" arity="0"/> - <fsummary>Returns and deletes the process dictionary.</fsummary> + <fsummary>Return and delete the process dictionary.</fsummary> <desc> <p>Returns the process dictionary and deletes it, for example:</p> @@ -1158,13 +1200,13 @@ b</pre> <func> <name name="erase" arity="1"/> - <fsummary>Returns and deletes a value from the process dictionary.</fsummary> + <fsummary>Return and delete a value from the process dictionary. + </fsummary> <desc> <p>Returns the value <c><anno>Val</anno></c> associated with <c><anno>Key</anno></c> and deletes it from the process dictionary. Returns <c>undefined</c> if no value is associated with - <c><anno>Key</anno></c>.</p> - <p>Example:</p> + <c><anno>Key</anno></c>. Example:</p> <pre> > <input>put(key1, {merry, lambs, are, playing}),</input> <input>X = erase(key1),</input> @@ -1175,16 +1217,15 @@ b</pre> <func> <name name="error" arity="1"/> - <fsummary>Stops execution with a given reason.</fsummary> + <fsummary>Stop execution with a specified reason.</fsummary> <desc> <p>Stops the execution of the calling process with the reason <c><anno>Reason</anno></c>, where <c><anno>Reason</anno></c> is any term. The exit reason is <c>{<anno>Reason</anno>, Where}</c>, where <c>Where</c> is a list of the functions most recently called (the current - function first). Since evaluating this function causes - the process to terminate, it has no return value.</p> - <p>Example:</p> + function first). As evaluating this function causes + the process to terminate, it has no return value. Example:</p> <pre> > <input>catch error(foobar).</input> {'EXIT',{foobar,[{erl_eval,do_apply,5}, @@ -1197,7 +1238,7 @@ b</pre> <func> <name name="error" arity="2"/> - <fsummary>Stops execution with a given reason.</fsummary> + <fsummary>Stop execution with a specified reason.</fsummary> <desc> <p>Stops the execution of the calling process with the reason <c><anno>Reason</anno></c>, where <c><anno>Reason</anno></c> @@ -1207,21 +1248,20 @@ b</pre> function first). <c><anno>Args</anno></c> is expected to be the list of arguments for the current function; in Beam it is used to provide the arguments for the current function in - the term <c>Where</c>. Since evaluating this function causes + the term <c>Where</c>. As evaluating this function causes the process to terminate, it has no return value.</p> </desc> </func> <func> <name name="exit" arity="1"/> - <fsummary>Stops execution with a given reason.</fsummary> + <fsummary>Stop execution with a specified reason.</fsummary> <desc> <p>Stops the execution of the calling process with exit reason <c><anno>Reason</anno></c>, where <c><anno>Reason</anno></c> - is any term. Since + is any term. As evaluating this function causes the process to terminate, it - has no return value.</p> - <p>Example:</p> + has no return value. Example:</p> <pre> > <input>exit(foobar).</input> ** exception exit: foobar @@ -1232,43 +1272,44 @@ b</pre> <func> <name name="exit" arity="2"/> - <fsummary>Sends an exit signal to a process or a port.</fsummary> + <fsummary>Send an exit signal to a process or a port.</fsummary> <desc> <p>Sends an exit signal with exit reason <c><anno>Reason</anno></c> to the process or port identified by <c><anno>Pid</anno></c>.</p> <p>The following behavior applies if <c><anno>Reason</anno></c> is any term, except <c>normal</c> or <c>kill</c>:</p> - <list type="bulleted"> - <item>If <c><anno>Pid</anno></c> is not trapping exits, - <c><anno>Pid</anno></c> - itself exits with exit reason <c><anno>Reason</anno></c>. - </item> - <item>If <c><anno>Pid</anno></c> is trapping exits, the exit - signal is transformed into a message - <c>{'EXIT', From, <anno>Reason</anno>}</c> - and delivered to the message queue of <c><anno>Pid</anno></c>. - </item> - <item><c>From</c> is the process identifier of the process - that sent the exit signal. See also - <seealso marker="#process_flag/2">process_flag/2</seealso>. - </item> - </list> - <p>If <c><anno>Reason</anno></c> is the atom <c>normal</c>, + <list type="bulleted"> + <item><p>If <c><anno>Pid</anno></c> is not trapping exits, <c><anno>Pid</anno></c> - does not exit. If it is trapping exits, the exit signal is - transformed into a message <c>{'EXIT', From, normal}</c> - and delivered to its message queue.</p> - <p>If <c><anno>Reason</anno></c> is the atom <c>kill</c>, - that is, if <c>exit(<anno>Pid</anno>, kill)</c> is called, - an untrappable exit signal is sent to <c><anno>Pid</anno></c>, - which unconditionally exits with exit reason <c>killed</c>. - </p> + itself exits with exit reason <c><anno>Reason</anno></c>.</p> + </item> + <item><p>If <c><anno>Pid</anno></c> is trapping exits, the exit + signal is transformed into a message + <c>{'EXIT', From, <anno>Reason</anno>}</c> + and delivered to the message queue of <c><anno>Pid</anno></c>.</p> + </item> + <item><p><c>From</c> is the process identifier of the process + that sent the exit signal. See also + <seealso marker="#process_flag/2"> + <c>process_flag/2</c></seealso>.</p> + </item> + </list> + <p>If <c><anno>Reason</anno></c> is the atom <c>normal</c>, + <c><anno>Pid</anno></c> + does not exit. If it is trapping exits, the exit signal is + transformed into a message <c>{'EXIT', From, normal}</c> + and delivered to its message queue.</p> + <p>If <c><anno>Reason</anno></c> is the atom <c>kill</c>, + that is, if <c>exit(<anno>Pid</anno>, kill)</c> is called, + an untrappable exit signal is sent to <c><anno>Pid</anno></c>, + which unconditionally exits with exit reason <c>killed</c>.</p> </desc> </func> <func> <name name="external_size" arity="1"/> - <fsummary>Calculates the maximum size for a term encoded in the Erlang external term format.</fsummary> + <fsummary>Calculate the maximum size for a term encoded in the Erlang + external term format.</fsummary> <desc> <p>Calculates, without doing the encoding, the maximum byte size for a term encoded in the Erlang external term format. The following @@ -1279,13 +1320,15 @@ b</pre> > <input>true = Size1 =< Size2.</input> true</pre> <p>This is equivalent to a call to:</p> -<code>erlang:external_size(<anno>Term</anno>, [])</code> +<code> +erlang:external_size(<anno>Term</anno>, [])</code> </desc> </func> <func> <name name="external_size" arity="2"/> - <fsummary>Calculates the maximum size for a term encoded in the Erlang external term format.</fsummary> + <fsummary>Calculate the maximum size for a term encoded in the Erlang + external term format.</fsummary> <desc> <p>Calculates, without doing the encoding, the maximum byte size for a term encoded in the Erlang external term format. The following @@ -1297,13 +1340,14 @@ true</pre> true</pre> <p>Option <c>{minor_version, <anno>Version</anno>}</c> specifies how floats are encoded. For a detailed description, see - <seealso marker="#term_to_binary/2">term_to_binary/2</seealso>.</p> + <seealso marker="#term_to_binary/2"> + <c>term_to_binary/2</c></seealso>.</p> </desc> </func> <func> <name name="float" arity="1"/> - <fsummary>Converts a number to a float.</fsummary> + <fsummary>Convert a number to a float.</fsummary> <desc> <p>Returns a float by converting <c><anno>Number</anno></c> to a float, for example:</p> @@ -1314,7 +1358,8 @@ true</pre> <note> <p>If used on the top level in a guard, it tests whether the argument is a floating point number; for clarity, use - <seealso marker="#is_float/1">is_float/1</seealso> instead.</p> + <seealso marker="#is_float/1"><c>is_float/1</c></seealso> + instead.</p> <p>When <c>float/1</c> is used in an expression in a guard, such as '<c>float(A) == 4.0</c>', it converts a number as described earlier.</p> @@ -1333,13 +1378,14 @@ true</pre> <func> <name name="float_to_binary" arity="2"/> - <fsummary>Text representation of a float formatted using given options.</fsummary> + <fsummary>Text representation of a float formatted using specified + options.</fsummary> <desc> <p>Returns a binary corresponding to the text representation of <c><anno>Float</anno></c> using fixed decimal point formatting. <c><anno>Options</anno></c> behaves in the same - way as <seealso marker="#float_to_list/2">float_to_list/2</seealso>.</p> - <p>Examples:</p> + way as <seealso marker="#float_to_list/2"> + <c>float_to_list/2</c></seealso>. Examples:</p> <pre> > <input>float_to_binary(7.12, [{decimals, 4}]).</input> <<"7.1200">> @@ -1359,27 +1405,29 @@ true</pre> <func> <name name="float_to_list" arity="2"/> - <fsummary>Text representation of a float formatted using given options.</fsummary> + <fsummary>Text representation of a float formatted using specified + options.</fsummary> <desc> <p>Returns a string corresponding to the text representation - of <c>Float</c> using fixed decimal point formatting. The - options are as follows:</p> + of <c>Float</c> using fixed decimal point formatting.</p> + <p>Available options:</p> <list type="bulleted"> - <item>If option <c>decimals</c> is specified, the returned value + <item><p>If option <c>decimals</c> is specified, the returned value contains at most <c>Decimals</c> number of digits past the - decimal point. If the number does not fit in the internal - static buffer of 256 bytes, the function throws <c>badarg</c>. + decimal point. If the number does not fit in the internal + static buffer of 256 bytes, the function throws <c>badarg</c>.</p> </item> - <item>If option <c>compact</c> is provided, the trailing zeros + <item><p>If option <c>compact</c> is specified, the trailing zeros at the end of the list are truncated. This option is only - meaningful together with option <c>decimals</c>. + meaningful together with option <c>decimals</c>.</p> </item> - <item>If option <c>scientific</c> is provided, the float is + <item><p>If option <c>scientific</c> is specified, the float is formatted using scientific notation with <c>Decimals</c> - digits of precision. + digits of precision.</p> </item> - <item>If <c>Options</c> is <c>[]</c>, the function behaves as - <seealso marker="#float_to_list/1">float_to_list/1</seealso>. + <item><p>If <c>Options</c> is <c>[]</c>, the function behaves as + <seealso marker="#float_to_list/1"> + <c>float_to_list/1</c></seealso>.</p> </item> </list> <p>Examples:</p> @@ -1406,16 +1454,16 @@ true</pre> </warning> <p>Two types of funs have slightly different semantics:</p> <list type="bulleted"> - <item>A fun created by <c>fun M:F/A</c> is called an + <item><p>A fun created by <c>fun M:F/A</c> is called an <em>external</em> fun. Calling it will always call the function <c>F</c> with arity <c>A</c> in the latest code for module <c>M</c>. Notice that module <c>M</c> does not even - need to be loaded when the fun <c>fun M:F/A</c> is created. + need to be loaded when the fun <c>fun M:F/A</c> is created.</p> </item> - <item>All other funs are called <em>local</em>. When a local fun + <item><p>All other funs are called <em>local</em>. When a local fun is called, the same version of the code that created the fun is called (even if a newer version of the module has been - loaded). + loaded).</p> </item> </list> <p>The following elements are always present in the list @@ -1479,14 +1527,14 @@ true</pre> <tag><c>{new_uniq, Uniq}</c></tag> <item> <p><c>Uniq</c> (a binary) is a unique value for this fun. It - is calculated from the compiled code for the entire module.</p> + is calculated from the compiled code for the entire module.</p> </item> <tag><c>{uniq, Uniq}</c></tag> <item> <p><c>Uniq</c> (an integer) is a unique value for this fun. - As from OTP R15, this integer is calculated from the - compiled code for the entire module. Before OTP R15, this - integer was based on only the body of the fun.</p> + As from Erlang/OTP R15, this integer is calculated from the + compiled code for the entire module. Before Erlang/OTP R15, this + integer was based on only the body of the fun.</p> </item> </taglist> </desc> @@ -1508,7 +1556,7 @@ true</pre> <c>uniq</c>, and <c>pid</c>. For an external fun, the value of any of these items is always the atom <c>undefined</c>.</p> <p>See - <seealso marker="#fun_info/1">erlang:fun_info/1</seealso>.</p> + <seealso marker="#fun_info/1"><c>erlang:fun_info/1</c></seealso>.</p> </desc> </func> @@ -1523,20 +1571,24 @@ true</pre> <func> <name name="function_exported" arity="3"/> - <fsummary>Checks if a function is exported and loaded.</fsummary> + <fsummary>Check if a function is exported and loaded.</fsummary> <desc> - <p>Returns <c>true</c> if the module <c><anno>Module</anno></c> is loaded - and contains an exported function <c><anno>Function</anno>/<anno>Arity</anno></c>, - or if there is a BIF (a built-in function implemented in C) - with the given name, otherwise returns <c>false</c>.</p> - <note><p>This function used to return false for built-in - functions before the 18.0 release.</p></note> + <p>Returns <c>true</c> if the module <c><anno>Module</anno></c> is + loaded and contains an exported function + <c><anno>Function</anno>/<anno>Arity</anno></c>, + or if there is a BIF (a built-in function implemented in C) + with the specified name, otherwise returns <c>false</c>.</p> + <note> + <p>This function used to return <c>false</c> for BIFs + before Erlang/OTP 18.0.</p> + </note> </desc> </func> <func> <name name="garbage_collect" arity="0"/> - <fsummary>Forces an immediate garbage collection of the calling process.</fsummary> + <fsummary>Force an immediate garbage collection of the calling process. + </fsummary> <desc> <p>Forces an immediate garbage collection of the executing process. The function is not to be used unless @@ -1551,73 +1603,76 @@ true</pre> <func> <name name="garbage_collect" arity="1"/> - <fsummary>Garbage collects a process.</fsummary> + <fsummary>Garbage collect a process.</fsummary> <desc> <p>The same as - <seealso marker="#garbage_collect/2"><c>garbage_collect(<anno>Pid</anno>, [])</c></seealso>.</p> + <seealso marker="#garbage_collect/2"> + <c>garbage_collect(<anno>Pid</anno>, [])</c></seealso>.</p> </desc> </func> <func> <name name="garbage_collect" arity="2"/> - <fsummary>Garbage collects a process.</fsummary> + <fsummary>Garbage collect a process.</fsummary> <desc> <p>Garbage collects the node local process identified by - <c><anno>Pid</anno></c>.</p> - <p>The available <c><anno>Option</anno></c>s are as follows:</p> + <c><anno>Pid</anno></c>.</p> + <p><c><anno>Option</anno></c>:</p> <taglist> <tag><c>{async, RequestId}</c></tag> <item>The function <c>garbage_collect/2</c> returns - the value <c>async</c> immediately after the request - has been sent. When the request has been processed, the - process that called this function is passed a message on + the value <c>async</c> immediately after the request + has been sent. When the request has been processed, the + process that called this function is passed a message on the form <c>{garbage_collect, <anno>RequestId</anno>, <anno>GCResult</anno>}</c>. </item> </taglist> - <p>If <c><anno>Pid</anno></c> equals <c>self()</c>, and - no <c>async</c> option has been passed, the garbage - collection is performed at once, that is, the same as calling - <seealso marker="#garbage_collect/0">garbage_collect/0</seealso>. - Otherwise a request for garbage collection - is sent to the process identified by <c><anno>Pid</anno></c>, - and will be handled when appropriate. If no <c>async</c> - option has been passed, the caller blocks until - <c><anno>GCResult</anno></c> is available and can be returned.</p> - <p><c><anno>GCResult</anno></c> informs about the result of - the garbage collection request as follows:</p> + <p>If <c><anno>Pid</anno></c> equals <c>self()</c>, and + no <c>async</c> option has been passed, the garbage + collection is performed at once, that is, the same as calling + <seealso marker="#garbage_collect/0"> + <c>garbage_collect/0</c></seealso>. + Otherwise a request for garbage collection + is sent to the process identified by <c><anno>Pid</anno></c>, + and will be handled when appropriate. If no <c>async</c> + option has been passed, the caller blocks until + <c><anno>GCResult</anno></c> is available and can be returned.</p> + <p><c><anno>GCResult</anno></c> informs about the result of + the garbage collection request as follows:</p> <taglist> <tag><c>true</c></tag> <item> - The process identified by <c><anno>Pid</anno></c> has - been garbage collected. - </item> + The process identified by <c><anno>Pid</anno></c> has + been garbage collected. + </item> <tag><c>false</c></tag> <item> - No garbage collection was performed, as - the process identified by <c><anno>Pid</anno></c> - terminated before the request could be satisfied. - </item> + No garbage collection was performed, as + the process identified by <c><anno>Pid</anno></c> + terminated before the request could be satisfied. + </item> </taglist> <p>Notice that the same caveats apply as for - <seealso marker="#garbage_collect/0">garbage_collect/0</seealso>.</p> + <seealso marker="#garbage_collect/0"> + <c>garbage_collect/0</c></seealso>.</p> <p>Failures:</p> <taglist> <tag><c>badarg</c></tag> <item> - If <c><anno>Pid</anno></c> is not a node local process identifier. - </item> + If <c><anno>Pid</anno></c> is not a node local process identifier. + </item> <tag><c>badarg</c></tag> <item> - If <c><anno>OptionList</anno></c> is an invalid list of options. - </item> + If <c><anno>OptionList</anno></c> is an invalid list of options. + </item> </taglist> </desc> </func> <func> <name name="get" arity="0"/> - <fsummary>Returns the process dictionary.</fsummary> + <fsummary>Return the process dictionary.</fsummary> <desc> <p>Returns the process dictionary as a list of <c>{<anno>Key</anno>, <anno>Val</anno>}</c> tuples, for example:</p> @@ -1632,12 +1687,11 @@ true</pre> <func> <name name="get" arity="1"/> - <fsummary>Returns a value from the process dictionary.</fsummary> + <fsummary>Return a value from the process dictionary.</fsummary> <desc> - <p>Returns the value <c><anno>Val</anno></c> associated with <c><anno>Key</anno></c> in - the process dictionary, or <c>undefined</c> if <c><anno>Key</anno></c> - does not exist.</p> - <p>Example:</p> + <p>Returns the value <c><anno>Val</anno></c> associated with + <c><anno>Key</anno></c> in the process dictionary, or <c>undefined</c> + if <c><anno>Key</anno></c> does not exist. Example:</p> <pre> > <input>put(key1, merry),</input> <input>put(key2, lambs),</input> @@ -1649,7 +1703,7 @@ true</pre> <func> <name name="get_cookie" arity="0"/> - <fsummary>Gets the magic cookie of the local node.</fsummary> + <fsummary>Get the magic cookie of the local node.</fsummary> <desc> <p>Returns the magic cookie of the local node if the node is alive, otherwise the atom <c>nocookie</c>.</p> @@ -1658,9 +1712,11 @@ true</pre> <func> <name name="get_keys" arity="0"/> - <fsummary>Return a list of all keys from the process dictionary</fsummary> + <fsummary>Return a list of all keys from the process dictionary. + </fsummary> <desc> - <p>Returns a list of keys all keys present in the process dictionary.</p> + <p>Returns a list of all keys present in the process dictionary, + for example:</p> <pre> > <input>put(dog, {animal,1}),</input> <input>put(cow, {animal,2}),</input> @@ -1669,9 +1725,10 @@ true</pre> [dog,cow,lamb]</pre> </desc> </func> + <func> <name name="get_keys" arity="1"/> - <fsummary>Returns a list of keys from the process dictionary.</fsummary> + <fsummary>Return a list of keys from the process dictionary.</fsummary> <desc> <p>Returns a list of keys that are associated with the value <c><anno>Val</anno></c> in the process dictionary, for example:</p> @@ -1689,48 +1746,49 @@ true</pre> <func> <name name="get_stacktrace" arity="0"/> - <fsummary>Gets the call stack back-trace of the last exception.</fsummary> + <fsummary>Get the call stack back-trace of the last exception.</fsummary> <type name="stack_item"/> <desc> <p>Gets the call stack back-trace (<em>stacktrace</em>) of the last exception in the calling process as a list of - <c>{<anno>Module</anno>,<anno>Function</anno>,<anno>Arity</anno>,<anno>Location</anno>}</c> tuples. - Field <c><anno>Arity</anno></c> in the first tuple can be the + <c>{<anno>Module</anno>,<anno>Function</anno>,<anno>Arity</anno>,<anno>Location</anno>}</c> + tuples. Field <c><anno>Arity</anno></c> in the first tuple can be the argument list of that function call instead of an arity integer, depending on the exception.</p> <p>If there has not been any exceptions in a process, the stacktrace is <c>[]</c>. After a code change for the process, the stacktrace can also be reset to <c>[]</c>.</p> - <p>The stacktrace is the same data as the <c>catch</c> operator + <p>The stacktrace is the same data as operator <c>catch</c> returns, for example:</p> - <p><c>{'EXIT',{badarg,Stacktrace}} = catch abs(x)</c></p> - <p><c><anno>Location</anno></c> is a (possibly empty) list + <pre> +{'EXIT',{badarg,Stacktrace}} = catch abs(x)</pre> + <p><c><anno>Location</anno></c> is a (possibly empty) list of two-tuples that - can indicate the location in the source code of the function. - The first element is an atom describing the type of - information in the second element. The following - items can occur:</p> - <taglist> - <tag><c>file</c></tag> - <item>The second element of the tuple is a string (list of - characters) representing the file name of the source file - of the function. - </item> - <tag><c>line</c></tag> - <item>The second element of the tuple is the line number - (an integer greater than zero) in the source file - where the exception occurred or the function was called. - </item> - </taglist> + can indicate the location in the source code of the function. + The first element is an atom describing the type of + information in the second element. The following + items can occur:</p> + <taglist> + <tag><c>file</c></tag> + <item>The second element of the tuple is a string (list of + characters) representing the filename of the source file + of the function. + </item> + <tag><c>line</c></tag> + <item>The second element of the tuple is the line number + (an integer > 0) in the source file + where the exception occurred or the function was called. + </item> + </taglist> <p>See also - <seealso marker="#error/1">erlang:error/1</seealso> and - <seealso marker="#error/2">erlang:error/2</seealso>.</p> + <seealso marker="#error/1"><c>error/1</c></seealso> and + <seealso marker="#error/2"><c>error/2</c></seealso>.</p> </desc> </func> <func> <name name="group_leader" arity="0"/> - <fsummary>Gets the group leader for the calling process.</fsummary> + <fsummary>Get the group leader for the calling process.</fsummary> <desc> <p>Returns the process identifier of the group leader for the process evaluating the function.</p> @@ -1738,14 +1796,14 @@ true</pre> groups have a <em>group leader</em>. All I/O from the group is channeled to the group leader. When a new process is spawned, it gets the same group leader as the spawning - process. Initially, at system start-up, <c>init</c> is both + process. Initially, at system startup, <c>init</c> is both its own group leader and the group leader of all processes.</p> </desc> </func> <func> <name name="group_leader" arity="2"/> - <fsummary>Sets the group leader for a process.</fsummary> + <fsummary>Set the group leader for a process.</fsummary> <desc> <p>Sets the group leader of <c><anno>Pid</anno></c> to <c><anno>GroupLeader</anno></c>. @@ -1753,72 +1811,72 @@ true</pre> certain shell is to have another group leader than <c>init</c>.</p> <p>See also - <seealso marker="#group_leader/0">group_leader/0</seealso>.</p> + <seealso marker="#group_leader/0"><c>group_leader/0</c></seealso>.</p> </desc> </func> <func> <name name="halt" arity="0"/> - <fsummary>Halts the Erlang runtime system and indicates normal exit to the calling environment.</fsummary> + <fsummary>Halt the Erlang runtime system and indicate normal exit to + the calling environment.</fsummary> <desc> - <p>The same as - <seealso marker="#halt/2"><c>halt(0, [])</c></seealso>.</p> - <p>Example:</p> + <p>The same as + <seealso marker="#halt/2"><c>halt(0, [])</c></seealso>. Example:</p> <pre> > <input>halt().</input> -os_prompt% </pre> +os_prompt%</pre> </desc> </func> <func> <name name="halt" arity="1"/> - <fsummary>Halts the Erlang runtime system.</fsummary> + <fsummary>Halt the Erlang runtime system.</fsummary> <desc> - <p>The same as - <seealso marker="#halt/2"><c>halt(<anno>Status</anno>, [])</c></seealso>.</p> - <p>Example:</p> + <p>The same as <seealso marker="#halt/2"> + <c>halt(<anno>Status</anno>, [])</c></seealso>. Example:</p> <pre> > <input>halt(17).</input> os_prompt% <input>echo $?</input> 17 -os_prompt% </pre> +os_prompt%</pre> </desc> </func> <func> <name name="halt" arity="2"/> - <fsummary>Halts the Erlang runtime system.</fsummary> + <fsummary>Halt the Erlang runtime system.</fsummary> <desc> <p><c><anno>Status</anno></c> must be a non-negative integer, a string, - or the atom <c>abort</c>. - Halts the Erlang runtime system. Has no return value. - Depending on <c><anno>Status</anno></c>, the following occurs:</p> - <taglist> - <tag>integer()</tag> - <item>The runtime system exits with integer value - <c><anno>Status</anno></c> - as status code to the calling environment (OS). - </item> - <tag>string()</tag> - <item>An Erlang crash dump is produced with <c><anno>Status</anno></c> - as slogan. Then the runtime system exits with status code <c>1</c>. - Note that only code points in the range 0-255 may be used - and the string will be truncated if longer than 200 characters. - </item> - <tag><c>abort</c></tag> - <item> - The runtime system aborts producing a core dump, if that is - enabled in the OS. - </item> - </taglist> - <note><p>On many platforms, the OS supports only status - codes 0-255. A too large status code will be truncated by clearing - the high bits.</p></note> - <p>For integer <c><anno>Status</anno></c>, the Erlang runtime system + or the atom <c>abort</c>. + Halts the Erlang runtime system. Has no return value. + Depending on <c><anno>Status</anno></c>, the following occurs:</p> + <taglist> + <tag>integer()</tag> + <item>The runtime system exits with integer value + <c><anno>Status</anno></c> + as status code to the calling environment (OS). + </item> + <tag>string()</tag> + <item>An Erlang crash dump is produced with <c><anno>Status</anno></c> + as slogan. Then the runtime system exits with status code <c>1</c>. + Note that only code points in the range 0-255 may be used + and the string will be truncated if longer than 200 characters. + </item> + <tag><c>abort</c></tag> + <item>The runtime system aborts producing a core dump, if that is + enabled in the OS. + </item> + </taglist> + <note> + <p>On many platforms, the OS supports only status + codes 0-255. A too large status code is truncated by clearing + the high bits.</p> + </note> + <p>For integer <c><anno>Status</anno></c>, the Erlang runtime system closes all ports and allows async threads to finish their operations before exiting. To exit without such flushing, use - <c><anno>Option</anno></c> as <c>{flush,false}</c>.</p> - <p>For statuses <c>string()</c> and <c>abort</c>, option + <c><anno>Option</anno></c> as <c>{flush,false}</c>.</p> + <p>For statuses <c>string()</c> and <c>abort</c>, option <c>flush</c> is ignored and flushing is <em>not</em> done.</p> </desc> </func> @@ -1830,13 +1888,15 @@ os_prompt% </pre> <p>Returns a hash value for <c><anno>Term</anno></c> within the range <c>1..<anno>Range</anno></c>. The maximum range is 1..2^27-1.</p> <warning> - <p>This BIF is deprecated, as the hash value can differ on - different architectures. The hash values for integer - terms higher than 2^27 and large binaries are + <p><em>This BIF is deprecated, as the hash value can differ on + different architectures.</em> The hash values for integer + terms > 2^27 and large binaries are poor. The BIF is retained for backward compatibility reasons (it can have been used to hash records into a file), but all new code is to use one of the BIFs - <c>erlang:phash/2</c> or <c>erlang:phash2/1,2</c> instead.</p> + <seealso marker="#phash/2"><c>erlang:phash/2</c></seealso> or + <seealso marker="#phash2/1"><c>erlang:phash2/1,2</c></seealso> + instead.</p> </warning> </desc> </func> @@ -1858,7 +1918,7 @@ os_prompt% </pre> <func> <name name="hibernate" arity="3"/> - <fsummary>Hibernates a process until a message is sent to it.</fsummary> + <fsummary>Hibernate a process until a message is sent to it.</fsummary> <desc> <p>Puts the calling process into a wait state where its memory allocation has been reduced as much as possible. This is @@ -1866,15 +1926,15 @@ os_prompt% </pre> soon.</p> <p>The process is awaken when a message is sent to it, and control resumes in <c><anno>Module</anno>:<anno>Function</anno></c> with - the arguments given by <c><anno>Args</anno></c> with the call + the arguments specified by <c><anno>Args</anno></c> with the call stack emptied, meaning that the process terminates when that function returns. Thus <c>erlang:hibernate/3</c> never returns to its caller.</p> <p>If the process has any message in its message queue, the process is awakened immediately in the same way as described earlier.</p> - <p>In more technical terms, what <c>erlang:hibernate/3</c> does - is the following. It discards the call stack for the process, + <p>In more technical terms, <c>erlang:hibernate/3</c> + discards the call stack for the process, and then garbage collects the process. After this, all live data is in one continuous heap. The heap is then shrunken to the exact same size as the live data @@ -1886,11 +1946,12 @@ os_prompt% </pre> size is changed to a size not smaller than the minimum heap size.</p> <p>Notice that emptying the call stack means that any surrounding - <c>catch</c> is removed and must be reinserted after + <c>catch</c> is removed and must be re-inserted after hibernation. One effect of this is that processes started using <c>proc_lib</c> (also indirectly, such as <c>gen_server</c> processes), are to use - <seealso marker="stdlib:proc_lib#hibernate/3">proc_lib:hibernate/3</seealso> + <seealso marker="stdlib:proc_lib#hibernate/3"> + <c>proc_lib:hibernate/3</c></seealso> instead, to ensure that the exception handler continues to work when the process wakes up.</p> </desc> @@ -1898,15 +1959,16 @@ os_prompt% </pre> <func> <name name="insert_element" arity="3"/> - <fsummary>Inserts an element at index in a tuple.</fsummary> - <type_desc variable="Index">1..tuple_size(<anno>Tuple1</anno>) + 1</type_desc> + <fsummary>Insert an element at index in a tuple.</fsummary> + <type_desc variable="Index">1..tuple_size(<anno>Tuple1</anno>) + + 1</type_desc> <desc> <p>Returns a new tuple with element <c><anno>Term</anno></c> - inserted at position - <c><anno>Index</anno></c> in tuple <c><anno>Tuple1</anno></c>. - All elements from position <c><anno>Index</anno></c> and upwards are - pushed one step higher in the new tuple <c><anno>Tuple2</anno></c>.</p> - <p>Example:</p> + inserted at position + <c><anno>Index</anno></c> in tuple <c><anno>Tuple1</anno></c>. + All elements from position <c><anno>Index</anno></c> and upwards are + pushed one step higher in the new tuple <c><anno>Tuple2</anno></c>. + Example:</p> <pre> > <input>erlang:insert_element(2, {one, two, three}, new).</input> {one,new,two,three}</pre> @@ -1930,8 +1992,8 @@ os_prompt% </pre> <fsummary>Text representation of an integer.</fsummary> <desc> <p>Returns a binary corresponding to the text - representation of <c><anno>Integer</anno></c> in base - <c><anno>Base</anno></c>, for example:</p> + representation of <c><anno>Integer</anno></c> in base + <c><anno>Base</anno></c>, for example:</p> <pre> > <input>integer_to_binary(1023, 16).</input> <<"3FF">></pre> @@ -1964,8 +2026,21 @@ os_prompt% </pre> </func> <func> + <name name="iolist_size" arity="1"/> + <fsummary>Size of an iolist.</fsummary> + <desc> + <p>Returns an integer, that is the size in bytes, + of the binary that would be the result of + <c>iolist_to_binary(<anno>Item</anno>)</c>, for example:</p> + <pre> +> <input>iolist_size([1,2|<<3,4>>]).</input> +4</pre> + </desc> + </func> + + <func> <name name="iolist_to_binary" arity="1"/> - <fsummary>Converts an iolist to a binary.</fsummary> + <fsummary>Convert an iolist to a binary.</fsummary> <desc> <p>Returns a binary that is made from the integers and binaries in <c><anno>IoListOrBinary</anno></c>, for example:</p> @@ -1982,21 +2057,8 @@ os_prompt% </pre> </func> <func> - <name name="iolist_size" arity="1"/> - <fsummary>Size of an iolist.</fsummary> - <desc> - <p>Returns an integer that is the size in bytes - of the binary that would be the result of - <c>iolist_to_binary(<anno>Item</anno>)</c>, for example:</p> - <pre> -> <input>iolist_size([1,2|<<3,4>>]).</input> -4</pre> - </desc> - </func> - - <func> <name name="is_alive" arity="0"/> - <fsummary>Checks whether the local node is alive.</fsummary> + <fsummary>Check whether the local node is alive.</fsummary> <desc> <p>Returns <c>true</c> if the local node is alive (that is, if the node can be part of a distributed system), otherwise @@ -2006,7 +2068,7 @@ os_prompt% </pre> <func> <name name="is_atom" arity="1"/> - <fsummary>Checks whether a term is an atom.</fsummary> + <fsummary>Check whether a term is an atom.</fsummary> <desc> <p>Returns <c>true</c> if <c><anno>Term</anno></c> is an atom, otherwise <c>false</c>.</p> @@ -2016,18 +2078,18 @@ os_prompt% </pre> <func> <name name="is_binary" arity="1"/> - <fsummary>Checks whether a term is a binary.</fsummary> + <fsummary>Check whether a term is a binary.</fsummary> <desc> <p>Returns <c>true</c> if <c><anno>Term</anno></c> is a binary, otherwise <c>false</c>.</p> - <p>A binary always contains a complete number of bytes.</p> + <p>A binary always contains a complete number of bytes.</p> <p>Allowed in guard tests.</p> </desc> </func> <func> <name name="is_bitstring" arity="1"/> - <fsummary>Checks whether a term is a bitstring.</fsummary> + <fsummary>Check whether a term is a bitstring.</fsummary> <desc> <p>Returns <c>true</c> if <c><anno>Term</anno></c> is a bitstring (including a binary), otherwise <c>false</c>.</p> @@ -2037,7 +2099,7 @@ os_prompt% </pre> <func> <name name="is_boolean" arity="1"/> - <fsummary>Checks whether a term is a boolean.</fsummary> + <fsummary>Check whether a term is a boolean.</fsummary> <desc> <p>Returns <c>true</c> if <c><anno>Term</anno></c> is the atom <c>true</c> or the atom <c>false</c> (that is, a boolean). @@ -2048,18 +2110,18 @@ os_prompt% </pre> <func> <name name="is_builtin" arity="3"/> - <fsummary>Checks if a function is a BIF implemented in C.</fsummary> + <fsummary>Check if a function is a BIF implemented in C.</fsummary> <desc> <p>This BIF is useful for builders of cross-reference tools.</p> <p>Returns <c>true</c> if <c><anno>Module</anno>:<anno>Function</anno>/<anno>Arity</anno></c> - is a BIF implemented in C, otherwise <c>false</c>.</p> + is a BIF implemented in C, otherwise <c>false</c>.</p> </desc> </func> <func> <name name="is_float" arity="1"/> - <fsummary>Checks whether a term is a float.</fsummary> + <fsummary>Check whether a term is a float.</fsummary> <desc> <p>Returns <c>true</c> if <c><anno>Term</anno></c> is a floating point number, otherwise <c>false</c>.</p> @@ -2069,7 +2131,7 @@ os_prompt% </pre> <func> <name name="is_function" arity="1"/> - <fsummary>Checks whether a term is a fun.</fsummary> + <fsummary>Check whether a term is a fun.</fsummary> <desc> <p>Returns <c>true</c> if <c><anno>Term</anno></c> is a fun, otherwise <c>false</c>.</p> @@ -2079,7 +2141,8 @@ os_prompt% </pre> <func> <name name="is_function" arity="2"/> - <fsummary>Checks whether a term is a fun with a given arity.</fsummary> + <fsummary>Check whether a term is a fun with a specified given arity. + </fsummary> <desc> <p>Returns <c>true</c> if <c><anno>Term</anno></c> is a fun that can be applied with <c><anno>Arity</anno></c> number of arguments, otherwise @@ -2090,7 +2153,7 @@ os_prompt% </pre> <func> <name name="is_integer" arity="1"/> - <fsummary>Checks whether a term is an integer.</fsummary> + <fsummary>Check whether a term is an integer.</fsummary> <desc> <p>Returns <c>true</c> if <c><anno>Term</anno></c> is an integer, otherwise <c>false</c>.</p> @@ -2100,7 +2163,7 @@ os_prompt% </pre> <func> <name name="is_list" arity="1"/> - <fsummary>Checks whether a term is a list.</fsummary> + <fsummary>Check whether a term is a list.</fsummary> <desc> <p>Returns <c>true</c> if <c><anno>Term</anno></c> is a list with zero or more elements, otherwise <c>false</c>.</p> @@ -2110,7 +2173,7 @@ os_prompt% </pre> <func> <name name="is_map" arity="1"/> - <fsummary>Checks whether a term is a map.</fsummary> + <fsummary>Check whether a term is a map.</fsummary> <desc> <p>Returns <c>true</c> if <c><anno>Term</anno></c> is a map, otherwise <c>false</c>.</p> @@ -2120,7 +2183,7 @@ os_prompt% </pre> <func> <name name="is_number" arity="1"/> - <fsummary>Checks whether a term is a number.</fsummary> + <fsummary>Check whether a term is a number.</fsummary> <desc> <p>Returns <c>true</c> if <c><anno>Term</anno></c> is an integer or a floating point number. Otherwise returns <c>false</c>.</p> @@ -2130,7 +2193,7 @@ os_prompt% </pre> <func> <name name="is_pid" arity="1"/> - <fsummary>Checks whether a term is a process identifier.</fsummary> + <fsummary>Check whether a term is a process identifier.</fsummary> <desc> <p>Returns <c>true</c> if <c><anno>Term</anno></c> is a process identifier, otherwise <c>false</c>.</p> @@ -2140,7 +2203,7 @@ os_prompt% </pre> <func> <name name="is_port" arity="1"/> - <fsummary>Checks whether a term is a port.</fsummary> + <fsummary>Check whether a term is a port.</fsummary> <desc> <p>Returns <c>true</c> if <c><anno>Term</anno></c> is a port identifier, otherwise <c>false</c>.</p> @@ -2150,26 +2213,26 @@ os_prompt% </pre> <func> <name name="is_process_alive" arity="1"/> - <fsummary>Checks whether a process is alive.</fsummary> + <fsummary>Check whether a process is alive.</fsummary> <desc> - <p><c><anno>Pid</anno></c> must refer to a process at the local node.</p> + <p><c><anno>Pid</anno></c> must refer to a process at the local + node.</p> <p>Returns <c>true</c> if the process exists and is alive, that is, is not exiting and has not exited. Otherwise returns - <c>false</c>. - </p> + <c>false</c>.</p> </desc> </func> <func> <name name="is_record" arity="2"/> - <fsummary>Checks whether a term appears to be a record.</fsummary> + <fsummary>Check whether a term appears to be a record.</fsummary> <desc> <p>Returns <c>true</c> if <c><anno>Term</anno></c> is a tuple and its first element is <c><anno>RecordTag</anno></c>. Otherwise returns <c>false</c>.</p> <note> <p>Normally the compiler treats calls to <c>is_record/2</c> - specially. It emits code to verify that <c><anno>Term</anno></c> + especially. It emits code to verify that <c><anno>Term</anno></c> is a tuple, that its first element is <c><anno>RecordTag</anno></c>, and that the size is correct. However, if <c><anno>RecordTag</anno></c> is @@ -2183,7 +2246,7 @@ os_prompt% </pre> <func> <name name="is_record" arity="3"/> - <fsummary>Checks whether a term appears to be a record.</fsummary> + <fsummary>Check whether a term appears to be a record.</fsummary> <desc> <p><c><anno>RecordTag</anno></c> must be an atom.</p> <p>Returns <c>true</c> if @@ -2202,7 +2265,7 @@ os_prompt% </pre> <func> <name name="is_reference" arity="1"/> - <fsummary>Checks whether a term is a reference.</fsummary> + <fsummary>Check whether a term is a reference.</fsummary> <desc> <p>Returns <c>true</c> if <c><anno>Term</anno></c> is a reference, otherwise <c>false</c>.</p> @@ -2212,7 +2275,7 @@ os_prompt% </pre> <func> <name name="is_tuple" arity="1"/> - <fsummary>Checks whether a term is a tuple.</fsummary> + <fsummary>Check whether a term is a tuple.</fsummary> <desc> <p>Returns <c>true</c> if <c><anno>Term</anno></c> is a tuple, otherwise <c>false</c>.</p> @@ -2234,7 +2297,7 @@ os_prompt% </pre> <func> <name name="link" arity="1"/> - <fsummary>Creates a link to another process (or port).</fsummary> + <fsummary>Create a link to another process (or port).</fsummary> <desc> <p>Creates a link between the calling process and another process (or port) <c><anno>PidOrPort</anno></c>, if there is @@ -2244,34 +2307,34 @@ os_prompt% </pre> <p>If <c><anno>PidOrPort</anno></c> does not exist, the behavior of the BIF depends on if the calling process is trapping exits or not (see - <seealso marker="#process_flag/2">process_flag/2</seealso>):</p> + <seealso marker="#process_flag/2"> + <c>process_flag/2</c></seealso>):</p> <list type="bulleted"> - <item>If the calling process is not trapping exits, and - checking <c><anno>PidOrPort</anno></c> is cheap - (that is, if <c><anno>PidOrPort</anno></c> - is local), <c>link/1</c> fails with reason <c>noproc</c>.</item> - <item>Otherwise, if the calling process is trapping exits, - and/or <c><anno>PidOrPort</anno></c> is remote, <c>link/1</c> - returns <c>true</c>, but an exit signal with reason <c>noproc</c> - is sent to the calling process.</item> + <item><p>If the calling process is not trapping exits, and + checking <c><anno>PidOrPort</anno></c> is cheap + (that is, if <c><anno>PidOrPort</anno></c> + is local), <c>link/1</c> fails with reason <c>noproc</c>.</p></item> + <item><p>Otherwise, if the calling process is trapping exits, + and/or <c><anno>PidOrPort</anno></c> is remote, <c>link/1</c> + returns <c>true</c>, but an exit signal with reason <c>noproc</c> + is sent to the calling process.</p></item> </list> </desc> </func> <func> <name name="list_to_atom" arity="1"/> - <fsummary>Converts from text representation to an atom.</fsummary> + <fsummary>Convert from text representation to an atom.</fsummary> <desc> <p>Returns the atom whose text representation is <c><anno>String</anno></c>.</p> - <p><c><anno>String</anno></c> can only contain ISO-latin-1 - characters (that is, - numbers less than 256) as the implementation does not - allow unicode characters equal to or above 256 in atoms. - For more information on Unicode support in atoms, see - <seealso marker="erl_ext_dist#utf8_atoms">note on UTF-8 + <p><c><anno>String</anno></c> can only contain ISO-latin-1 + characters (that is, numbers < 256) as the implementation does not + allow Unicode characters equal to or above 256 in atoms. + For more information on Unicode support in atoms, see + <seealso marker="erl_ext_dist#utf8_atoms">note on UTF-8 encoded atoms</seealso> - in Section "External Term Format" in the User's Guide.</p> + in section "External Term Format" in the User's Guide.</p> <p>Example:</p> <pre> > <input>list_to_atom("Erlang").</input> @@ -2281,7 +2344,7 @@ os_prompt% </pre> <func> <name name="list_to_binary" arity="1"/> - <fsummary>Converts a list to a binary.</fsummary> + <fsummary>Convert a list to a binary.</fsummary> <desc> <p>Returns a binary that is made from the integers and binaries in <c><anno>IoList</anno></c>, for example:</p> @@ -2299,13 +2362,13 @@ os_prompt% </pre> <func> <name name="list_to_bitstring" arity="1"/> - <fsummary>Converts a list to a bitstring.</fsummary> + <fsummary>Convert a list to a bitstring.</fsummary> <type name="bitstring_list"/> <desc> <p>Returns a bitstring that is made from the integers and bitstrings in <c><anno>BitstringList</anno></c>. (The last tail in - <c><anno>BitstringList</anno></c> is allowed to be a bitstring.)</p> - <p>Example:</p> + <c><anno>BitstringList</anno></c> is allowed to be a bitstring.) + Example:</p> <pre> > <input>Bin1 = <<1,2,3>>.</input> <<1,2,3>> @@ -2320,7 +2383,7 @@ os_prompt% </pre> <func> <name name="list_to_existing_atom" arity="1"/> - <fsummary>Converts from text representation to an atom.</fsummary> + <fsummary>Convert from text representation to an atom.</fsummary> <desc> <p>Returns the atom whose text representation is <c><anno>String</anno></c>, @@ -2332,7 +2395,7 @@ os_prompt% </pre> <func> <name name="list_to_float" arity="1"/> - <fsummary>Converts from text representation to a float.</fsummary> + <fsummary>Convert from text representation to a float.</fsummary> <desc> <p>Returns the float whose text representation is <c><anno>String</anno></c>, for example:</p> @@ -2346,7 +2409,7 @@ os_prompt% </pre> <func> <name name="list_to_integer" arity="1"/> - <fsummary>Converts from text representation to an integer.</fsummary> + <fsummary>Convert from text representation to an integer.</fsummary> <desc> <p>Returns an integer whose text representation is <c><anno>String</anno></c>, for example:</p> @@ -2360,7 +2423,7 @@ os_prompt% </pre> <func> <name name="list_to_integer" arity="2"/> - <fsummary>Converts from text representation to an integer.</fsummary> + <fsummary>Convert from text representation to an integer.</fsummary> <desc> <p>Returns an integer whose text representation in base <c><anno>Base</anno></c> is <c><anno>String</anno></c>, @@ -2375,7 +2438,7 @@ os_prompt% </pre> <func> <name name="list_to_pid" arity="1"/> - <fsummary>Converts from text representation to a pid.</fsummary> + <fsummary>Convert from text representation to a pid.</fsummary> <desc> <p>Returns a process identifier whose text representation is a <c><anno>String</anno></c>, for example:</p> @@ -2386,14 +2449,14 @@ os_prompt% </pre> representation of a process identifier.</p> <warning> <p>This BIF is intended for debugging and is not to be used - in application programs.</p> + in application programs.</p> </warning> </desc> </func> <func> <name name="list_to_tuple" arity="1"/> - <fsummary>Converts a list to a tuple.</fsummary> + <fsummary>Convert a list to a tuple.</fsummary> <desc> <p>Returns a tuple corresponding to <c><anno>List</anno></c>, for example</p> @@ -2406,7 +2469,7 @@ os_prompt% </pre> <func> <name name="load_module" arity="2"/> - <fsummary>Loads object code for a module.</fsummary> + <fsummary>Load object code for a module.</fsummary> <desc> <p>If <c><anno>Binary</anno></c> contains the object code for module <c><anno>Module</anno></c>, this BIF loads that object code. If @@ -2417,23 +2480,21 @@ os_prompt% </pre> that code.</p> <p>Returns either <c>{module, <anno>Module</anno>}</c>, or <c>{error, <anno>Reason</anno>}</c> if loading fails. - <c><anno>Reason</anno></c> is any of the following:</p> + <c><anno>Reason</anno></c> is one of the following:</p> <taglist> <tag><c>badfile</c></tag> - <item> - <p>The object code in <c><anno>Binary</anno></c> has an - incorrect format <em>or</em> the object code contains code - for another module than <c><anno>Module</anno></c>.</p> + <item>The object code in <c><anno>Binary</anno></c> has an + incorrect format <em>or</em> the object code contains code + for another module than <c><anno>Module</anno></c>. </item> <tag><c>not_purged</c></tag> - <item> - <p><c><anno>Binary</anno></c> contains a module that cannot be - loaded because old code for this module already exists.</p> + <item><c><anno>Binary</anno></c> contains a module that cannot be + loaded because old code for this module already exists. </item> </taglist> <warning> <p>This BIF is intended for the code server (see - <seealso marker="kernel:code">code(3)</seealso>) + <seealso marker="kernel:code"><c>kernel:code(3)</c></seealso>) and is not to be used elsewhere.</p> </warning> </desc> @@ -2441,33 +2502,36 @@ os_prompt% </pre> <func> <name name="load_nif" arity="2"/> - <fsummary>Loads NIF library.</fsummary> + <fsummary>Load NIF library.</fsummary> <desc> <note> - <p>Before OTP R14B, NIFs were an - experimental feature. Versions before OTP R14B can - have different and possibly incompatible NIF semantics and - interfaces. For example, in OTP R13B03 the return value on - failure was <c>{error,Reason,Text}</c>.</p> + <p>Before Erlang/OTP R14B, NIFs were an + experimental feature. Versions before Erlang/OTP R14B can + have different and possibly incompatible NIF semantics and + interfaces. For example, in Erlang/OTP R13B03 the return value on + failure was <c>{error,Reason,Text}</c>.</p> </note> <p>Loads and links a dynamic library containing native - implemented functions (NIFs) for a module. <c><anno>Path</anno></c> - is a file path to the shareable object/dynamic library file minus - the OS-dependent file extension (<c>.so</c> for Unix and - <c>.dll</c> for Windows. For information on how to - implement a NIF library, see - <seealso marker="erl_nif">erl_nif</seealso>.</p> + implemented functions (NIFs) for a module. <c><anno>Path</anno></c> + is a file path to the shareable object/dynamic library file minus + the OS-dependent file extension (<c>.so</c> for Unix and + <c>.dll</c> for Windows). Notice that on most OSs the library has + to have a different name on disc when an upgrade of the nif is + done. If the name is the same, but the contents differ, the + old library may be loaded instead. For information on how to + implement a NIF library, see + <seealso marker="erl_nif"><c>erl_nif(3)</c></seealso>.</p> <p><c><anno>LoadInfo</anno></c> can be any term. It is passed on to - the library as part of the initialization. A good practice is - to include a module version number to support future code - upgrade scenarios.</p> + the library as part of the initialization. A good practice is + to include a module version number to support future code + upgrade scenarios.</p> <p>The call to <c>load_nif/2</c> must be made - <em>directly</em> from the Erlang code of the module that the - NIF library belongs to. It returns either <c>ok</c>, or - <c>{error,{<anno>Reason</anno>,Text}}</c> if loading fails. - <c><anno>Reason</anno></c> is one of the following atoms - while <c><anno>Text</anno></c> is a human readable string that - can give more information about the failure:</p> + <em>directly</em> from the Erlang code of the module that the + NIF library belongs to. It returns either <c>ok</c>, or + <c>{error,{<anno>Reason</anno>,Text}}</c> if loading fails. + <c><anno>Reason</anno></c> is one of the following atoms + while <c><anno>Text</anno></c> is a human readable string that + can give more information about the failure:</p> <taglist> <tag><c>load_failed</c></tag> <item>The OS failed to load the NIF library. @@ -2490,11 +2554,12 @@ os_prompt% </pre> <func> <name name="loaded" arity="0"/> - <fsummary>Lists all loaded modules.</fsummary> + <fsummary>List all loaded modules.</fsummary> <desc> <p>Returns a list of all loaded Erlang modules (current and old code), including preloaded modules.</p> - <p>See also <seealso marker="kernel:code">code(3)</seealso>.</p> + <p>See also <seealso marker="kernel:code"> + <c>kernel:code(3)</c></seealso>.</p> </desc> </func> @@ -2515,13 +2580,13 @@ os_prompt% </pre> <func> <name name="localtime_to_universaltime" arity="1"/> - <fsummary>Converts from local to Universal Time Coordinated (UTC) date and time.</fsummary> + <fsummary>Convert from local to Universal Time Coordinated (UTC) date + and time.</fsummary> <desc> <p>Converts local date and time to Universal Time Coordinated (UTC), if supported by the underlying OS. Otherwise no conversion is done and <c><anno>Localtime</anno></c> - is returned.</p> - <p>Example:</p> + is returned. Example:</p> <pre> > <input>erlang:localtime_to_universaltime({{1996,11,6},{14,45,17}}).</input> {{1996,11,6},{13,45,17}}</pre> @@ -2532,15 +2597,16 @@ os_prompt% </pre> <func> <name name="localtime_to_universaltime" arity="2"/> - <fsummary>Converts from local to Universal Time Coordinated (UTC) date and time.</fsummary> + <fsummary>Convert from local to Universal Time Coordinated (UTC) date + and time.</fsummary> <desc> <p>Converts local date and time to Universal Time Coordinated (UTC) as <c>erlang:localtime_to_universaltime/1</c>, but the caller decides if Daylight Saving Time is active.</p> - <p>If <c><anno>IsDst</anno> == true</c>, <c><anno>Localtime</anno></c> is - during Daylight Saving Time, if <c><anno>IsDst</anno> == false</c> it is - not. If <c><anno>IsDst</anno> == undefined</c>, the underlying OS can - guess, which is the same as calling + <p>If <c><anno>IsDst</anno> == true</c>, <c><anno>Localtime</anno></c> + is during Daylight Saving Time, if <c><anno>IsDst</anno> == false</c> + it is not. If <c><anno>IsDst</anno> == undefined</c>, the underlying + OS can guess, which is the same as calling <c>erlang:localtime_to_universaltime(<anno>Localtime</anno>)</c>.</p> <p>Examples:</p> <pre> @@ -2557,24 +2623,27 @@ os_prompt% </pre> <func> <name name="make_ref" arity="0"/> - <fsummary>Returns a unique reference.</fsummary> + <fsummary>Return a unique reference.</fsummary> <desc> - <p>Returns a <seealso marker="doc/efficiency_guide:advanced#unique_references">unique - reference</seealso>. The reference is unique among - connected nodes.</p> - <warning><p>Known issue: When a node is restarted multiple - times with the same node name, references created - on a newer node can be mistaken for a reference - created on an older node with the same node name.</p></warning> + <p>Returns a + <seealso marker="doc/efficiency_guide:advanced#unique_references"> + unique reference</seealso>. The reference is unique among + connected nodes.</p> + <warning> + <p>Known issue: When a node is restarted multiple + times with the same node name, references created + on a newer node can be mistaken for a reference + created on an older node with the same node name.</p> + </warning> </desc> </func> <func> <name name="make_tuple" arity="2"/> - <fsummary>Creates a new tuple of a given arity.</fsummary> + <fsummary>Create a new tuple of a specified arity.</fsummary> <desc> - <p>Creates a new tuple of the given <c><anno>Arity</anno></c>, where all - elements are <c><anno>InitialValue</anno></c>, for example:</p> + <p>Creates a new tuple of the specified <c><anno>Arity</anno></c>, where + all elements are <c><anno>InitialValue</anno></c>, for example:</p> <pre> > <input>erlang:make_tuple(4, []).</input> {[],[],[],[]}</pre> @@ -2583,17 +2652,16 @@ os_prompt% </pre> <func> <name name="make_tuple" arity="3"/> - <fsummary>Creates a new tuple with given arity and contents.</fsummary> + <fsummary>Create a new tuple with specifed arity and contents.</fsummary> <desc> <p>Creates a tuple of size <c><anno>Arity</anno></c>, where each element has value <c><anno>DefaultValue</anno></c>, and then fills in - values from <c><anno>InitList</anno></c>. + values from <c><anno>InitList</anno></c>. Each list element in <c><anno>InitList</anno></c> - must be a two-tuple, where the first element is a position in the - newly created tuple and the second element is any term. If a - position occurs more than once in the list, the term corresponding - to the last occurrence is used.</p> - <p>Example:</p> + must be a two-tuple, where the first element is a position in the + newly created tuple and the second element is any term. If a + position occurs more than once in the list, the term corresponding + to the last occurrence is used. Example:</p> <pre> > <input>erlang:make_tuple(5, [], [{2,ignored},{5,zz},{2,aa}]).</input> {{[],aa,[],[],zz}</pre> @@ -2602,7 +2670,7 @@ os_prompt% </pre> <func> <name name="map_size" arity="1"/> - <fsummary>Returns the size of a map.</fsummary> + <fsummary>Return the size of a map.</fsummary> <desc> <p>Returns an integer, which is the number of key-value pairs in <c><anno>Map</anno></c>, for example:</p> @@ -2615,74 +2683,74 @@ os_prompt% </pre> <func> <name name="match_spec_test" arity="3"/> - <fsummary>Test that a match specification works</fsummary> - <desc> - <p> - This function is a utility to test a match_spec used in calls to - <seealso marker="stdlib:ets#select/2">ets:select/2</seealso> and - <seealso marker="#trace_pattern/3">erlang:trace_pattern/3</seealso>. - The function both tests MatchSpec for "syntactic" correctness and - runs the match_spec against the object. If the match_spec contains - errors, the tuple {error, Errors} is returned where Errors is a list - of natural language descriptions of what was wrong with the match_spec. - </p> - <p> - If the <c><anno>Type</anno></c> is <c>table</c> the object to match - against should be a tuple. The function then returns - {ok,Result,[],Warnings} where Result is what would have been the - result in a real ets:select/2 call or false if the match_spec does - not match the object tuple. - </p> - - <p> - If <c><anno>Type</anno></c> is <c>trace</c> the object to match - against should be a list. The function returns - {ok, Result, Flags, Warnings} where Result is <c>true</c> if a trace - message should be emitted, <c>false</c> if a trace message should not - be emitted or the message term to be appended to the trace message. - Flags is a list containing all the trace flags that will be enabled, - at the moment this is only <c>return_trace</c>. - </p> - - <p> - This is a useful debugging and test tool, especially when writing complicated - match specifications. - </p> - <p> - See also - <seealso marker="stdlib:ets#test_ms/2">ets:test_ms/2</seealso>. - </p> + <fsummary>Test that a match specification works.</fsummary> + <desc> + <p>Tests a match specification used in calls to + <seealso marker="stdlib:ets#select/2"><c>ets:select/2</c></seealso> + and <seealso marker="#trace_pattern/3"> + <c>erlang:trace_pattern/3</c></seealso>. + The function tests both a match specification for "syntactic" + correctness and runs the match specification against the object. If + the match specification contains errors, the tuple <c>{error, + Errors}</c> is returned, where <c>Errors</c> is a list of natural + language descriptions of what was wrong with the match + specification.</p> + <p>If <c><anno>Type</anno></c> is <c>table</c>, the object to match + against is to be a tuple. The function then returns + <c>{ok,Result,[],Warnings}</c>, where <c>Result</c> is what would + have been the result in a real <c>ets:select/2</c> call, or + <c>false</c> if the match specification does not match the object + tuple.</p> + <p>If <c><anno>Type</anno></c> is <c>trace</c>, the object to match + against is to be a list. The function returns + <c>{ok, Result, Flags, Warnings}</c>, where <c>Result</c> is one of + the following:</p> + <list type="bulleted"> + <item><c>true</c> if a trace message is to be emitted</item> + <item><c>false</c> if a trace message is not to be emitted</item> + <item>The message term to be appended to the trace message</item> + </list> + <p><c>Flags</c> is a list containing all the trace flags to be enabled, + currently this is only <c>return_trace</c>.</p> + <p>This is a useful debugging and test tool, especially when writing + complicated match specifications.</p> + <p>See also + <seealso marker="stdlib:ets#test_ms/2"><c>ets:test_ms/2</c></seealso>.</p> </desc> </func> <func> <name name="max" arity="2"/> - <fsummary>Returns the largest of two terms.</fsummary> + <fsummary>Return the largest of two terms.</fsummary> <desc> <p>Returns the largest of <c><anno>Term1</anno></c> and <c><anno>Term2</anno></c>. - If the terms are equal, <c><anno>Term1</anno></c> is returned.</p> + If the terms are equal, <c><anno>Term1</anno></c> is returned.</p> </desc> </func> <func> <name name="md5" arity="1"/> - <fsummary>Computes an MD5 message digest.</fsummary> + <fsummary>Compute an MD5 message digest.</fsummary> <desc> <p>Computes an MD5 message digest from <c><anno>Data</anno></c>, where the length of the digest is 128 bits (16 bytes). <c><anno>Data</anno></c> is a binary or a list of small integers and binaries.</p> - <p>For more information about MD5, see RFC 1321 - The - MD5 Message-Digest Algorithm.</p> - <warning><p>The MD5 Message-Digest Algorithm is <em>not</em> considered - safe for code-signing or software-integrity purposes.</p></warning> + <p>For more information about MD5, see + <url href="https://www.ietf.org/rfc/rfc1321.txt"> + RFC 1321 - The MD5 Message-Digest Algorithm</url>.</p> + <warning> + <p>The MD5 Message-Digest Algorithm is <em>not</em> considered + safe for code-signing or software-integrity purposes.</p> + </warning> </desc> </func> <func> <name name="md5_final" arity="1"/> - <fsummary>Finishes the update of an MD5 context and returns the computed MD5 message digest.</fsummary> + <fsummary>Finish the update of an MD5 context and return the computed + MD5 message digest.</fsummary> <desc> <p>Finishes the update of an MD5 <c><anno>Context</anno></c> and returns the computed <c>MD5</c> message digest.</p> @@ -2691,18 +2759,19 @@ os_prompt% </pre> <func> <name name="md5_init" arity="0"/> - <fsummary>Creates an MD5 context.</fsummary> + <fsummary>Create an MD5 context.</fsummary> <desc> - <p>Creates an MD5 context, to be used in subsequent calls to + <p>Creates an MD5 context, to be used in the following calls to <c>md5_update/2</c>.</p> </desc> </func> <func> <name name="md5_update" arity="2"/> - <fsummary>Updates an MD5 context with data and returns a new context.</fsummary> + <fsummary>Update an MD5 context with data and return a new context. + </fsummary> <desc> - <p>Updates an MD5 <c><anno>Context</anno></c> with + <p>Update an MD5 <c><anno>Context</anno></c> with <c><anno>Data</anno></c> and returns a <c><anno>NewContext</anno></c>.</p> </desc> @@ -2718,7 +2787,7 @@ os_prompt% </pre> element is a tuple <c>{Type, Size}</c>. The first element <c><anno>Type</anno></c> is an atom describing memory type. The second element <c><anno>Size</anno></c> is the memory size in bytes.</p> - <p>The memory types are as follows:</p> + <p>Memory types:</p> <taglist> <tag><c>total</c></tag> <item> @@ -2770,7 +2839,7 @@ os_prompt% </pre> </item> <tag><c>ets</c></tag> <item> - <p>The total amount of memory currently allocated for ets + <p>The total amount of memory currently allocated for <c>ets</c> tables. This memory is part of the memory presented as <c>system</c> memory.</p> </item> @@ -2778,9 +2847,9 @@ os_prompt% </pre> <item> <p>Only on 64-bit halfword emulator. The total amount of memory allocated in low memory areas - that are restricted to less than 4 GB, although - the system can have more memory.</p> - <p>Can be removed in a future release of the halfword + that are restricted to < 4 GB, although + the system can have more memory.</p> + <p>Can be removed in a future release of the halfword emulator.</p> </item> <tag><c>maximum</c></tag> @@ -2790,8 +2859,9 @@ os_prompt% </pre> when the emulator is run with instrumentation.</p> <p>For information on how to run the emulator with instrumentation, see - <seealso marker="tools:instrument">instrument(3)</seealso> - and/or <seealso marker="erts:erl">erl(1)</seealso>.</p> + <seealso marker="tools:instrument"> + <c>tools:instrument(3)</c></seealso> + and/or <seealso marker="erl"><c>erl(1)</c></seealso>.</p> </item> </taglist> <note> @@ -2808,20 +2878,20 @@ os_prompt% </pre> <p>As the <c>total</c> value is the sum of <c>processes</c> and <c>system</c>, the error in <c>system</c> propagates to the <c>total</c> value.</p> - <p>The different amounts of memory that are summed are - <em>not</em> gathered atomically, which introduces - an error in the result.</p> + <p>The different amounts of memory that are summed are + <em>not</em> gathered atomically, which introduces + an error in the result.</p> </note> <p>The different values have the following relation to each other. Values beginning with an uppercase letter is not part of the result.</p> <code type="none"> - total = processes + system - processes = processes_used + ProcessesNotUsed - system = atom + binary + code + ets + OtherSystem - atom = atom_used + AtomNotUsed - RealTotal = processes + RealSystem - RealSystem = system + MissedSystem</code> +total = processes + system +processes = processes_used + ProcessesNotUsed +system = atom + binary + code + ets + OtherSystem +atom = atom_used + AtomNotUsed +RealTotal = processes + RealSystem +RealSystem = system + MissedSystem</code> <p>More tuples in the returned list can be added in a future release.</p> <note> @@ -2831,20 +2901,20 @@ os_prompt% </pre> the emulator stacks are not supposed to be included. That is, the <c>total</c> value is <em>not</em> supposed to be equal to the total size of all pages mapped to the emulator.</p> - <p>Furthermore, because of fragmentation and prereservation of + <p>Also, because of fragmentation and prereservation of memory areas, the size of the memory segments containing the dynamically allocated memory blocks can be much larger than the total size of the dynamically allocated memory blocks.</p> </note> - <note> - <p>As from <c>ERTS</c> 5.6.4, <c>erlang:memory/0</c> requires that - all <seealso marker="erts:erts_alloc">erts_alloc(3)</seealso> - allocators are enabled (default behavior).</p> - </note> + <note> + <p>As from <c>ERTS</c> 5.6.4, <c>erlang:memory/0</c> requires that + all <seealso marker="erts:erts_alloc"><c>erts_alloc(3)</c></seealso> + allocators are enabled (default behavior).</p> + </note> <p>Failure: <c>notsup</c> if an - <seealso marker="erts:erts_alloc">erts_alloc(3)</seealso> - allocator has been disabled.</p> + <seealso marker="erts:erts_alloc"><c>erts_alloc(3)</c></seealso> + allocator has been disabled.</p> </desc> </func> @@ -2854,61 +2924,61 @@ os_prompt% </pre> <fsummary>Information about dynamically allocated memory.</fsummary> <type name="memory_type"/> <desc> - <p>Returns the memory size in bytes allocated for memory of - type <c><anno>Type</anno></c>. The argument can also be given as a list + <p>Returns the memory size in bytes allocated for memory of type + <c><anno>Type</anno></c>. The argument can also be specified as a list of <c>memory_type()</c> atoms, in which case a corresponding list of <c>{memory_type(), Size :: integer >= 0}</c> tuples is returned.</p> - <note> - <p>As from <c>ERTS</c> version 5.6.4, + <note> + <p>As from <c>ERTS</c> 5.6.4, <c>erlang:memory/1</c> requires that - all <seealso marker="erts:erts_alloc">erts_alloc(3)</seealso> - allocators are enabled (default behavior).</p> - </note> + all <seealso marker="erts_alloc"><c>erts_alloc(3)</c></seealso> + allocators are enabled (default behavior).</p> + </note> <p>Failures:</p> <taglist> <tag><c>badarg</c></tag> <item> - If <c><anno>Type</anno></c> is not one of the memory types + If <c><anno>Type</anno></c> is not one of the memory types listed in the description of - <seealso marker="#memory/0">erlang:memory/0</seealso>. - </item> + <seealso marker="#memory/0"><c>erlang:memory/0</c></seealso>. + </item> <tag><c>badarg</c></tag> <item> - If <c>maximum</c> is passed as <c><anno>Type</anno></c> and + If <c>maximum</c> is passed as <c><anno>Type</anno></c> and the emulator is not run in instrumented mode. - </item> + </item> <tag><c>notsup</c></tag> <item> - If an <seealso marker="erts:erts_alloc">erts_alloc(3)</seealso> - allocator has been disabled. - </item> - </taglist> + If an <seealso marker="erts_alloc"><c>erts_alloc(3)</c></seealso> + allocator has been disabled. + </item> + </taglist> <p>See also - <seealso marker="#memory/0">erlang:memory/0</seealso>.</p> + <seealso marker="#memory/0"><c>erlang:memory/0</c></seealso>.</p> </desc> </func> <func> <name name="min" arity="2"/> - <fsummary>Returns the smallest of two terms.</fsummary> + <fsummary>Return the smallest of two terms.</fsummary> <desc> <p>Returns the smallest of <c><anno>Term1</anno></c> and <c><anno>Term2</anno></c>. - If the terms are equal, <c><anno>Term1</anno></c> is returned.</p> + If the terms are equal, <c><anno>Term1</anno></c> is returned.</p> </desc> </func> <func> <name name="module_loaded" arity="1"/> - <fsummary>Checks if a module is loaded.</fsummary> + <fsummary>Check if a module is loaded.</fsummary> <desc> <p>Returns <c>true</c> if the module <c><anno>Module</anno></c> is loaded, otherwise <c>false</c>. It does not attempt to load the module.</p> <warning> <p>This BIF is intended for the code server (see - <seealso marker="kernel:code">code(3)</seealso>) and is not to be - used elsewhere.</p> + <seealso marker="kernel:code"><c>kernel:code(3)</c></seealso>) + and is not to be used elsewhere.</p> </warning> </desc> </func> @@ -2917,7 +2987,7 @@ os_prompt% </pre> <name name="monitor" arity="2" clause_i="1"/> <name name="monitor" arity="2" clause_i="2"/> <name name="monitor" arity="2" clause_i="3"/> - <fsummary>Starts monitoring.</fsummary> + <fsummary>Start monitoring.</fsummary> <type name="registered_name"/> <type name="registered_process_identifier"/> <type name="monitor_process_identifier"/> @@ -2925,35 +2995,39 @@ os_prompt% </pre> <desc> <p>Sends a monitor request of type <c><anno>Type</anno></c> to the entity identified by <c><anno>Item</anno></c>. If the monitored entity - does not exist or when it dies, the caller of <c>monitor/2</c> will - be notified by a message on the following format:</p> - <code type="none">{Tag, <anno>MonitorRef</anno>, <anno>Type</anno>, Object, Info}</code> - <note><p>The monitor request is an asynchronous signal. That is, it - takes time before the signal reaches its destination.</p></note> + does not exist or it changes monitored state, the caller of + <c>monitor/2</c> is notified by a message on the following format:</p> + <code type="none"> +{Tag, <anno>MonitorRef</anno>, <anno>Type</anno>, Object, Info}</code> + <note> + <p>The monitor request is an asynchronous signal. That is, it + takes time before the signal reaches its destination.</p> + </note> <p><c><anno>Type</anno></c> can be one of the following atoms: <c>process</c>, <c>port</c> or <c>time_offset</c>.</p> - <p>A monitor is triggered only once, after that it is removed from - both monitoring process and the monitored entity. - Monitors are fired when the monitored process or port terminates, - does not exist at the moment of creation, or if the connection to - it is lost. In the case with connection, we lose knowledge about - the fact if it still exists or not. The monitoring is also turned off - when <seealso marker="#demonitor/1">demonitor/1</seealso> - is called.</p> - - <p>When monitoring by name please note, that the <c>RegisteredName</c> - is resolved to <c>pid()</c> or <c>port()</c> only once - at the moment of monitor instantiation, later changes to the name - registration will not affect the existing monitor.</p> - - <p>When a monitor is triggered, a <c>'DOWN'</c> message that has the - following pattern <c>{'DOWN', MonitorRef, Type, Object, Info}</c> - is sent to the monitoring process.</p> - - <p>In monitor message <c>MonitorRef</c> and <c>Type</c> are the same as - described earlier, and:</p> + <p>A <c>process</c> or <c>port</c> monitor is triggered only once, + after that it is removed from both monitoring process and + the monitored entity. Monitors are fired when the monitored process + or port terminates, does not exist at the moment of creation, + or if the connection to it is lost. If the connection to it is lost, + we do not know if it still exists. The monitoring is also turned off + when <seealso marker="#demonitor/1">demonitor/1</seealso> is + called.</p> + + <p>A <c>process</c> or <c>port</c> monitor by name + resolves the <c>RegisteredName</c> to <c>pid()</c> or <c>port()</c> + only once at the moment of monitor instantiation, later changes to + the name registration will not affect the existing monitor.</p> + + <p>When a <c>process</c> or <c>port</c> monitor is triggered, + a <c>'DOWN'</c> message is sent that has the following pattern:</p> + <code type="none"> +{'DOWN', MonitorRef, Type, Object, Info}</code> + + <p>In the monitor message <c>MonitorRef</c> and <c>Type</c> are the + same as described earlier, and:</p> <taglist> <tag><c>Object</c></tag> <item> @@ -2980,14 +3054,14 @@ os_prompt% </pre> implemented), the call fails with <c>badarg</c>.</p> <note> <p>The format of the <c>'DOWN'</c> message changed in ERTS - version 5.2 (OTP R9B) for monitoring + 5.2 (Erlang/OTP R9B) for monitoring <em>by registered name</em>. Element <c>Object</c> of the <c>'DOWN'</c> message could in earlier versions sometimes be the process identifier of the monitored process and sometimes be the registered name. Now element <c>Object</c> is always a tuple consisting of the registered name and - the node name. Processes on new nodes (ERTS version 5.2 - or higher) always get <c>'DOWN'</c> messages on + the node name. Processes on new nodes (ERTS 5.2 + or higher versions) always get <c>'DOWN'</c> messages on the new format even if they are monitoring processes on old nodes. Processes on old nodes always get <c>'DOWN'</c> messages on the old format.</p> @@ -2996,11 +3070,11 @@ os_prompt% </pre> <taglist> <tag>Monitoring a <marker id="monitor_process"/><c>process</c></tag> <item> - <p>Creates monitor between the current process and another - process identified by <c><anno>Item</anno></c>, which can be a - <c>pid()</c> (local or remote), an atom <c>RegisteredName</c> or - a tuple <c>{RegisteredName, Node}</c> for a registered process, - located elsewhere.</p> + <p>Creates monitor between the current process and another + process identified by <c><anno>Item</anno></c>, which can be a + <c>pid()</c> (local or remote), an atom <c>RegisteredName</c> or + a tuple <c>{RegisteredName, Node}</c> for a registered process, + located elsewhere.</p> </item> <tag>Monitoring a <marker id="monitor_port"/><c>port</c></tag> @@ -3016,60 +3090,62 @@ os_prompt% </pre> <tag>Monitoring a <marker id="monitor_time_offset"/><c>time_offset</c></tag> <item> - <p>Monitor changes in - <seealso marker="#time_offset/0">time offset</seealso> - between - <seealso marker="time_correction#Erlang_Monotonic_Time">Erlang - monotonic time</seealso> and - <seealso marker="time_correction#Erlang_System_Time">Erlang - system time</seealso>. There is only one valid - <c><anno>Item</anno></c> in combination with the - <c>time_offset <anno>Type</anno></c>, namely the atom - <c>clock_service</c>. Note that the atom <c>clock_service</c> is - <em>not</em> the registered name of a process. In this specific - case it serves as an identifier of the runtime system internal - clock service at current runtime system instance.</p> + <p>Monitors changes in + <seealso marker="#time_offset/0"><c>time offset</c></seealso> + between + <seealso marker="time_correction#Erlang_Monotonic_Time">Erlang + monotonic time</seealso> and + <seealso marker="time_correction#Erlang_System_Time">Erlang + system time</seealso>. One valid <c><anno>Item</anno></c> + exists in combination with the + <c>time_offset <anno>Type</anno></c>, namely the atom + <c>clock_service</c>. Notice that the atom <c>clock_service</c> is + <em>not</em> the registered name of a process. In this + case it serves as an identifier of the runtime system internal + clock service at current runtime system instance.</p> <p>The monitor is triggered when the time offset is changed. - This either if the time offset value is changed, or if the - offset is changed from preliminary to final during - <seealso marker="#system_flag_time_offset">finalization - of the time offset</seealso> when the - <seealso marker="time_correction#Single_Time_Warp_Mode">single - time warp mode</seealso> is used. When a change from preliminary - to final time offset is made, the monitor will be triggered once - regardless of whether the time offset value was actually changed - or not.</p> + This either if the time offset value is changed, or if the + offset is changed from preliminary to final during + <seealso marker="#system_flag_time_offset">finalization + of the time offset</seealso> when the + <seealso marker="time_correction#Single_Time_Warp_Mode">single + time warp mode</seealso> is used. When a change from preliminary + to final time offset is made, the monitor is triggered once + regardless of whether the time offset value was changed + or not.</p> <p>If the runtime system is in - <seealso marker="time_correction#Multi_Time_Warp_Mode">multi - time warp mode</seealso>, the time offset will be changed when - the runtime system detects that the - <seealso marker="time_correction#OS_System_Time">OS system - time</seealso> has changed. The runtime system will, however, - not detect this immediately when it happens. A task checking - the time offset is scheduled to execute at least once a minute, - so under normal operation this should be detected within a - minute, but during heavy load it might take longer time.</p> - - <p>The monitor will <em>not</em> be automatically removed - after it has been triggered. That is, repeated changes of - the time offset will trigger the monitor repeatedly.</p> - - <p>When the monitor is triggered a <c>'CHANGE'</c> message will - be sent to the monitoring process. A <c>'CHANGE'</c> message has - the following pattern:</p> - <code type="none">{'CHANGE', MonitorRef, Type, Item, NewTimeOffset}</code> - <p>where <c>MonitorRef</c>, <c><anno>Type</anno></c>, and - <c><anno>Item</anno></c> are the same as described above, and - <c>NewTimeOffset</c> is the new time offset.</p> + <seealso marker="time_correction#Multi_Time_Warp_Mode">multi + time warp mode</seealso>, the time offset is changed when + the runtime system detects that the + <seealso marker="time_correction#OS_System_Time">OS system + time</seealso> has changed. The runtime system does, however, + not detect this immediately when it occurs. A task checking + the time offset is scheduled to execute at least once a minute, + so under normal operation this is to be detected within a + minute, but during heavy load it can take longer time.</p> + + <p>The monitor is <em>not</em> automatically removed + after it has been triggered. That is, repeated changes of + the time offset trigger the monitor repeatedly.</p> + + <p>When the monitor is triggered a <c>'CHANGE'</c> message is + sent to the monitoring process. A <c>'CHANGE'</c> message has + the following pattern:</p> + <code type="none"> +{'CHANGE', MonitorRef, Type, Item, NewTimeOffset}</code> + <p>where <c>MonitorRef</c>, <c><anno>Type</anno></c>, and + <c><anno>Item</anno></c> are the same as described above, and + <c>NewTimeOffset</c> is the new time offset.</p> <p>When the <c>'CHANGE'</c> message has been received you are - guaranteed not to retrieve the old time offset when calling - <seealso marker="#time_offset/0"><c>erlang:time_offset()</c></seealso>. - Note that you can observe the change of the time offset - when calling <c>erlang:time_offset()</c> before you - get the <c>'CHANGE'</c> message.</p> + guaranteed not to retrieve the old time offset when calling + <seealso marker="#time_offset/0"> + <c>erlang:time_offset()</c></seealso>. + Notice that you can observe the change of the time offset + when calling <c>erlang:time_offset()</c> before you + get the <c>'CHANGE'</c> message.</p> </item> </taglist> @@ -3080,20 +3156,19 @@ os_prompt% </pre> <p>The monitor functionality is expected to be extended. That is, other <c><anno>Type</anno></c>s and <c><anno>Item</anno></c>s are expected to be supported in a future release.</p> - <note> <p>If or when <c>monitor/2</c> is extended, other - possible values for <c>Tag</c>, <c>Object</c> and - <c>Info</c> in the monitor message will be introduced.</p> + possible values for <c>Tag</c>, <c>Object</c>, and + <c>Info</c> in the monitor message will be introduced.</p> </note> </desc> </func> <func> <name name="monitor_node" arity="2"/> - <fsummary>Monitors the status of a node.</fsummary> + <fsummary>Monitor the status of a node.</fsummary> <desc> - <p>Monitors the status of the node <c><anno>Node</anno></c>. + <p>Monitor the status of the node <c><anno>Node</anno></c>. If <c><anno>Flag</anno></c> is <c>true</c>, monitoring is turned on. If <c><anno>Flag</anno></c> is <c>false</c>, monitoring is turned off.</p> @@ -3115,12 +3190,12 @@ os_prompt% </pre> <func> <name name="monitor_node" arity="3"/> - <fsummary>Monitors the status of a node.</fsummary> + <fsummary>Monitor the status of a node.</fsummary> <desc> <p>Behaves as - <seealso marker="#monitor_node/2">monitor_node/2</seealso> + <seealso marker="#monitor_node/2"><c>monitor_node/2</c></seealso> except that it allows an - extra option to be given, namely <c>allow_passive_connect</c>. + extra option to be specified, namely <c>allow_passive_connect</c>. This option allows the BIF to wait the normal network connection time-out for the <em>monitored node</em> to connect itself, even if it cannot be actively connected from this node @@ -3143,70 +3218,77 @@ os_prompt% </pre> <name name="monotonic_time" arity="0"/> <fsummary>Current Erlang monotonic time.</fsummary> <desc> - <p>Returns the current - <seealso marker="time_correction#Erlang_Monotonic_Time">Erlang - monotonic time</seealso> in <c>native</c> - <seealso marker="#type_time_unit">time unit</seealso>. This - is a monotonically increasing time since some unspecified point in - time.</p> - - <note><p>This is a - <seealso marker="time_correction#Monotonically_Increasing">monotonically increasing</seealso> time, but <em>not</em> a - <seealso marker="time_correction#Strictly_Monotonically_Increasing">strictly monotonically increasing</seealso> - time. That is, consecutive calls to - <c>erlang:monotonic_time/0</c> can produce the same result.</p> - - <p>Different runtime system instances will use different - unspecified points in time as base for their Erlang monotonic clocks. - That is, it is <em>pointless</em> comparing monotonic times from - different runtime system instances. Different runtime system instances - may also place this unspecified point in time different relative - runtime system start. It may be placed in the future (time at start - is a negative value), the past (time at start is a - positive value), or the runtime system start (time at start is - zero). The monotonic time at runtime system start can be - retrieved by calling - <seealso marker="#system_info_start_time"><c>erlang:system_info(start_time)</c></seealso>.</p></note> + <p>Returns the current + <seealso marker="time_correction#Erlang_Monotonic_Time">Erlang + monotonic time</seealso> in <c>native</c> + <seealso marker="#type_time_unit">time unit</seealso>. This + is a monotonically increasing time since some unspecified point in + time.</p> + <note> + <p>This is a + <seealso marker="time_correction#Monotonically_Increasing"> + monotonically increasing</seealso> time, but <em>not</em> a + <seealso marker="time_correction#Strictly_Monotonically_Increasing"> + strictly monotonically increasing</seealso> + time. That is, consecutive calls to + <c>erlang:monotonic_time/0</c> can produce the same result.</p> + <p>Different runtime system instances will use different unspecified + points in time as base for their Erlang monotonic clocks. + That is, it is <em>pointless</em> comparing monotonic times from + different runtime system instances. Different runtime system + instances can also place this unspecified point in time different + relative runtime system start. It can be placed in the future (time + at start is a negative value), the past (time at start is a + positive value), or the runtime system start (time at start is + zero). The monotonic time at runtime system start can be + retrieved by calling + <seealso marker="#system_info_start_time"> + <c>erlang:system_info(start_time)</c></seealso>.</p> + </note> </desc> </func> + <func> <name name="monotonic_time" arity="1"/> - <fsummary>Current Erlang monotonic time</fsummary> + <fsummary>Current Erlang monotonic time.</fsummary> <desc> - <p>Returns the current - <seealso marker="time_correction#Erlang_Monotonic_Time">Erlang - monotonic time</seealso> converted - into the <c><anno>Unit</anno></c> passed as argument.</p> - - <p>Same as calling - <seealso marker="#convert_time_unit/3"><c>erlang:convert_time_unit</c></seealso><c>(</c><seealso marker="#monotonic_time/0"><c>erlang:monotonic_time()</c></seealso><c>, - native, <anno>Unit</anno>)</c> - however optimized for commonly used <c><anno>Unit</anno></c>s.</p> + <p>Returns the current + <seealso marker="time_correction#Erlang_Monotonic_Time">Erlang + monotonic time</seealso> converted + into the <c><anno>Unit</anno></c> passed as argument.</p> + <p>Same as calling + <seealso marker="#convert_time_unit/3"> + <c>erlang:convert_time_unit</c></seealso><c>(</c><seealso + marker="#monotonic_time/0"> + <c>erlang:monotonic_time()</c></seealso><c>, + native, <anno>Unit</anno>)</c>, + however optimized for commonly used <c><anno>Unit</anno></c>s.</p> </desc> </func> + <func> <name name="nif_error" arity="1"/> - <fsummary>Stops execution with a given reason.</fsummary> + <fsummary>Stop execution with a specified reason.</fsummary> <desc> <p>Works exactly like - <seealso marker="#error/1">erlang:error/1</seealso>, but - <c>Dialyzer</c> thinks that this BIF will return an arbitrary - term. When used in a stub function for a NIF to generate an - exception when the NIF library is not loaded, <c>Dialyzer</c> - does not generate false warnings.</p> + <seealso marker="#error/1"><c>error/1</c></seealso>, but + <c>Dialyzer</c> thinks that this BIF will return an arbitrary + term. When used in a stub function for a NIF to generate an + exception when the NIF library is not loaded, <c>Dialyzer</c> + does not generate false warnings.</p> </desc> </func> <func> <name name="nif_error" arity="2"/> - <fsummary>Stops execution with a given reason.</fsummary> + <fsummary>Stop execution with a specified reason.</fsummary> <desc> <p>Works exactly like - <seealso marker="#error/2">erlang:error/2</seealso>, but - <c>Dialyzer</c> thinks that this BIF will return an arbitrary - term. When used in a stub function for a NIF to generate an - exception when the NIF library is not loaded, <c>Dialyzer</c> - does not generate false warnings.</p> + <seealso marker="#error/2"><c>error/2</c></seealso>, but + <c>Dialyzer</c> thinks that this BIF will return an arbitrary + term. When used in a stub function for a NIF to generate an + exception when the NIF library is not loaded, <c>Dialyzer</c> + does not generate false warnings.</p> </desc> </func> @@ -3246,10 +3328,10 @@ os_prompt% </pre> <name name="nodes" arity="1"/> <fsummary>All nodes of a certain type in the system.</fsummary> <desc> - <p>Returns a list of nodes according to the argument given. - The returned result when the argument is a list, is the list + <p>Returns a list of nodes according to the argument specified. + The returned result, when the argument is a list, is the list of nodes satisfying the disjunction(s) of the list elements.</p> - <p><c><anno>NodeType</anno></c> can be any of the following:</p> + <p><c><anno>NodeType</anno></c>s:</p> <taglist> <tag><c>visible</c></tag> <item> @@ -3270,13 +3352,13 @@ os_prompt% </pre> <tag><c>known</c></tag> <item> <p>Nodes that are known to this node. That is, connected - nodes and nodes referred to by process identifiers, port - identifiers and references located on this node. - The set of known nodes is garbage collected. Notice that - this garbage collection can be delayed. For more - information, see - <seealso marker="erlang#system_info_delayed_node_table_gc">delayed_node_table_gc</seealso>. - </p> + nodes and nodes referred to by process identifiers, port + identifiers, and references located on this node. + The set of known nodes is garbage collected. Notice that + this garbage collection can be delayed. For more + information, see + <seealso marker="erlang#system_info_delayed_node_table_gc"> + <c>erlang:system_info(delayed_node_table_gc)</c></seealso>.</p> </item> </taglist> <p>Some equalities: <c>[node()] = nodes(this)</c>, @@ -3290,20 +3372,22 @@ os_prompt% </pre> <fsummary>Elapsed time since 00:00 GMT.</fsummary> <type name="timestamp"/> <desc> - <warning><p><em>This function is deprecated! Do not use it!</em> - See the users guide chapter - <seealso marker="time_correction">Time and Time Correction</seealso> - for more information. Specifically the - <seealso marker="time_correction#Dos_and_Donts">Dos and Dont's</seealso> - section for information on what to use instead of <c>erlang:now/0</c>. - </p></warning> - <p>Returns the tuple <c>{MegaSecs, Secs, MicroSecs}</c> which is + <warning> + <p><em>This function is deprecated. Do not use it.</em></p> + <p>For more information, see section + <seealso marker="time_correction">Time and Time Correction</seealso> + in the User's Guide. Specifically, section + <seealso marker="time_correction#Dos_and_Donts"> + Dos and Dont's</seealso> describes what to use instead of + <c>erlang:now/0</c>.</p> + </warning> + <p>Returns the tuple <c>{MegaSecs, Secs, MicroSecs}</c>, which is the elapsed time since 00:00 GMT, January 1, 1970 (zero hour), - on the assumption that the underlying OS supports this. + if provided by the underlying OS. Otherwise some other point in time is chosen. It is also - guaranteed that subsequent calls to this BIF return + guaranteed that the following calls to this BIF return continuously increasing values. Hence, the return value from - <c>now()</c> can be used to generate unique time-stamps. + <c>erlang:now/0</c> can be used to generate unique time stamps. If it is called in a tight loop on a fast machine, the time of the node can become skewed.</p> <p>Can only be used to check the local time of day if @@ -3314,28 +3398,31 @@ os_prompt% </pre> <func> <name name="open_port" arity="2"/> - <fsummary>Opens a port.</fsummary> + <fsummary>Open a port.</fsummary> <desc> <p>Returns a port identifier as the result of opening a new Erlang port. A port can be seen as an external Erlang process.</p> - <p>The name of the executable as well as the arguments - given in <c>cd</c>, <c>env</c>, <c>args</c>, and <c>arg0</c> are - subject to Unicode file name translation if the system is running - in Unicode file name mode. To avoid - translation or to force, for example UTF-8, supply the executable - and/or arguments as a binary in the correct - encoding. For details, see the module - <seealso marker="kernel:file">file</seealso>, the function - <seealso marker="kernel:file#native_name_encoding/0">file:native_name_encoding/0</seealso>, and the - <seealso marker="stdlib:unicode_usage">STDLIB </seealso> - User's Guide.</p> - <note><p>The characters in the name (if given as a list) can - only be higher than 255 if the Erlang Virtual Machine is started - in Unicode file name translation mode. Otherwise the name - of the executable is limited to the ISO-latin-1 - character set.</p></note> - <p><c><anno>PortName</anno></c> can be any of the following:</p> + <p>The name of the executable as well as the arguments + specifed in <c>cd</c>, <c>env</c>, <c>args</c>, and <c>arg0</c> are + subject to Unicode filename translation if the system is running + in Unicode filename mode. To avoid + translation or to force, for example UTF-8, supply the executable + and/or arguments as a binary in the correct + encoding. For details, see the module + <seealso marker="kernel:file"><c>kernel:file(3)</c></seealso>, the + function <seealso marker="kernel:file#native_name_encoding/0"> + <c>file:native_name_encoding/0</c></seealso> in <c>Kernel</c>, and + the <seealso marker="stdlib:unicode_usage"> + <c>Using Unicode in Erlang</c></seealso> User's Guide.</p> + <note> + <p>The characters in the name (if specified as a list) can + only be > 255 if the Erlang virtual machine is started + in Unicode filename translation mode. Otherwise the name + of the executable is limited to the ISO Latin-1 + character set.</p> + </note> + <p><c><anno>PortName</anno></c>s:</p> <taglist> <tag><c>{spawn, <anno>Command</anno>}</c></tag> <item> @@ -3354,55 +3441,57 @@ os_prompt% </pre> <c>vfork</c>, setting environment variable <c>ERL_NO_VFORK</c> to any value causes <c>fork</c> to be used instead.</p> - <p>For external programs, <c>PATH</c> is searched - (or an equivalent method is used to find programs, - depending on OS). This is done by invoking - the shell on certain platforms. The first space-separated - token of the command is considered as the - name of the executable (or driver). This (among other - things) makes this option unsuitable for running - programs having spaces in file names or directory names. - If spaces in executable file names are desired, use - <c>{spawn_executable, <anno>Command</anno>}</c> instead.</p> + <p>For external programs, <c>PATH</c> is searched + (or an equivalent method is used to find programs, + depending on the OS). This is done by invoking + the shell on certain platforms. The first space-separated + token of the command is considered as the + name of the executable (or driver). This (among other + things) makes this option unsuitable for running + programs with spaces in filenames or directory names. + If spaces in executable filenames are desired, use + <c>{spawn_executable, <anno>Command</anno>}</c> instead.</p> </item> <tag><c>{spawn_driver, <anno>Command</anno>}</c></tag> <item> - <p>Works like <c>{spawn, <anno>Command</anno>}</c>, but demands the - first (space-separated) token of the command to be the name of a - loaded driver. If no driver with that name is loaded, a - <c>badarg</c> error is raised.</p> + <p>Works like <c>{spawn, <anno>Command</anno>}</c>, but demands + the first (space-separated) token of the command to be the name + of a loaded driver. If no driver with that name is loaded, a + <c>badarg</c> error is raised.</p> </item> <tag><c>{spawn_executable, <anno>FileName</anno>}</c></tag> <item> - <p>Works like <c>{spawn, <anno>FileName</anno>}</c>, but only runs - external executables. <c><anno>FileName</anno></c> in its whole - is used as the name of the executable, including any spaces. - If arguments are to be passed, the <c><anno>PortSettings</anno></c> - <c>args</c> and <c>arg0</c> can be used.</p> - <p>The shell is usually not invoked to start the - program, it is executed directly. <c>PATH</c> (or + <p>Works like <c>{spawn, <anno>FileName</anno>}</c>, but only runs + external executables. <c><anno>FileName</anno></c> in its whole + is used as the name of the executable, including any spaces. + If arguments are to be passed, the + <c><anno>PortSettings</anno></c> + <c>args</c> and <c>arg0</c> can be used.</p> + <p>The shell is usually not invoked to start the + program, it is executed directly. <c>PATH</c> (or equivalent) is not searched. To find a program - in <c>PATH</c> to execute, use - <seealso marker="kernel:os#find_executable/1">os:find_executable/1</seealso>.</p> - <p>Only if a shell script or <c>.bat</c> file is - executed, the appropriate command interpreter is - invoked implicitly, but there is still no - command argument expansion or implicit <c>PATH</c> search.</p> - <p>If <c><anno>FileName</anno></c> cannot be run, an error - exception is raised, with the POSIX error code as the reason. - The error reason can differ between OSs. - Typically the error <c>enoent</c> is raised when an - attempt is made to run a program that is not found and - <c>eacces</c> is raised when the given file is not - executable.</p> + in <c>PATH</c> to execute, use + <seealso marker="kernel:os#find_executable/1"> + <c>os:find_executable/1</c></seealso>.</p> + <p>Only if a shell script or <c>.bat</c> file is + executed, the appropriate command interpreter is + invoked implicitly, but there is still no + command-argument expansion or implicit <c>PATH</c> search.</p> + <p>If <c><anno>FileName</anno></c> cannot be run, an error + exception is raised, with the POSIX error code as the reason. + The error reason can differ between OSs. + Typically the error <c>enoent</c> is raised when an + attempt is made to run a program that is not found and + <c>eacces</c> is raised when the specified file is not + executable.</p> </item> <tag><c>{fd, <anno>In</anno>, <anno>Out</anno>}</c></tag> <item> <p>Allows an Erlang process to access any currently opened file descriptors used by Erlang. The file descriptor - <c><anno>In</anno></c> can be used for standard input, and the file - descriptor <c><anno>Out</anno></c> for standard output. It is only - used for various servers in the Erlang OS (<c>shell</c> + <c><anno>In</anno></c> can be used for standard input, and the + file descriptor <c><anno>Out</anno></c> for standard output. + It is only used for various servers in the Erlang OS (<c>shell</c> and <c>user</c>). Hence, its use is limited.</p> </item> </taglist> @@ -3411,7 +3500,8 @@ os_prompt% </pre> <taglist> <tag><c>{packet, <anno>N</anno>}</c></tag> <item> - <p>Messages are preceded by their length, sent in <c><anno>N</anno></c> + <p>Messages are preceded by their length, sent in + <c><anno>N</anno></c> bytes, with the most significant byte first. The valid values for <c>N</c> are 1, 2, and 4.</p> </item> @@ -3424,16 +3514,16 @@ os_prompt% </pre> <tag><c>{line, <anno>L</anno>}</c></tag> <item> <p>Messages are delivered on a per line basis. Each line - (delimited by the OS-dependent new line sequence) is + (delimited by the OS-dependent newline sequence) is delivered in a single message. The message data format is <c>{Flag, Line}</c>, where <c>Flag</c> is <c>eol</c> or <c>noeol</c>, and <c>Line</c> is the - data delivered (without the new line sequence).</p> + data delivered (without the newline sequence).</p> <p><c><anno>L</anno></c> specifies the maximum line length in bytes. Lines longer than this are delivered in more than one message, with <c>Flag</c> set to <c>noeol</c> for all but the last message. If end of file is encountered - anywhere else than immediately following a new line + anywhere else than immediately following a newline sequence, the last line is also delivered with <c>Flag</c> set to <c>noeol</c>. Otherwise lines are delivered with <c>Flag</c> set to <c>eol</c>.</p> @@ -3443,14 +3533,14 @@ os_prompt% </pre> <tag><c>{cd, <anno>Dir</anno>}</c></tag> <item> <p>Only valid for <c>{spawn, <anno>Command</anno>}</c> and - <c>{spawn_executable, <anno>FileName</anno>}</c>. + <c>{spawn_executable, <anno>FileName</anno>}</c>. The external program starts using <c><anno>Dir</anno></c> as its working directory. <c><anno>Dir</anno></c> must be a string.</p> </item> <tag><c>{env, <anno>Env</anno>}</c></tag> <item> - <p>Only valid for <c>{spawn, <anno>Command</anno>}</c> and - <c>{spawn_executable, <anno>FileName</anno>}</c>. + <p>Only valid for <c>{spawn, <anno>Command</anno>}</c>, and + <c>{spawn_executable, <anno>FileName</anno>}</c>. The environment of the started process is extended using the environment specifications in <c><anno>Env</anno></c>.</p> <p><c><anno>Env</anno></c> is to be a list of tuples @@ -3461,56 +3551,58 @@ os_prompt% </pre> port process. Both <c><anno>Name</anno></c> and <c><anno>Val</anno></c> must be strings. The one exception is <c><anno>Val</anno></c> being the atom - <c>false</c> (in analogy with <c>os:getenv/1</c>), which - removes the environment variable.</p> - </item> - <tag><c>{args, [ string() | binary() ]}</c></tag> - <item> - <p>Only valid for <c>{spawn_executable, <anno>FileName</anno>}</c> - and specifies arguments to the executable. Each argument - is given as a separate string and (on Unix) eventually - ends up as one element each in the argument vector. On - other platforms, a similar behavior is mimicked.</p> - <p>The arguments are not expanded by the shell before - being supplied to the executable. Most notably this - means that file wild card expansion does not happen. - To expand wild cards for the arguments, use - <seealso marker="stdlib:filelib#wildcard/1">filelib:wildcard/1</seealso>. - Notice that even if - the program is a Unix shell script, meaning that the - shell ultimately is invoked, wild card expansion - does not happen, and the script is provided with the - untouched arguments. On Windows, wild card expansion - is always up to the program itself, therefore this is - not an issue issue.</p> - <p>The executable name (also known as <c>argv[0]</c>) - is not to be given in this list. The proper executable name - is automatically used as argv[0], where applicable.</p> - <p>If you explicitly want to set the - program name in the argument vector, option <c>arg0</c> - can be used.</p> - </item> - <tag><c>{arg0, string() | binary()}</c></tag> - <item> - <p>Only valid for <c>{spawn_executable, <anno>FileName</anno>}</c> - and explicitly specifies the program name argument when - running an executable. This can in some circumstances, - on some OSs, be desirable. How the program - responds to this is highly system-dependent and no specific - effect is guaranteed.</p> - </item> + <c>false</c> (in analogy with + <seealso marker="kernel:os#getenv/1"><c>os:getenv/1</c></seealso>, + which removes the environment variable.</p> + </item> + <tag><c>{args, [ string() | binary() ]}</c></tag> + <item> + <p>Only valid for <c>{spawn_executable, <anno>FileName</anno>}</c> + and specifies arguments to the executable. Each argument + is specified as a separate string and (on Unix) eventually + ends up as one element each in the argument vector. On + other platforms, a similar behavior is mimicked.</p> + <p>The arguments are not expanded by the shell before + they are supplied to the executable. Most notably this + means that file wildcard expansion does not occur. + To expand wildcards for the arguments, use + <seealso marker="stdlib:filelib#wildcard/1"> + <c>filelib:wildcard/1</c></seealso>. + Notice that even if + the program is a Unix shell script, meaning that the + shell ultimately is invoked, wildcard expansion + does not occur, and the script is provided with the + untouched arguments. On Windows, wildcard expansion + is always up to the program itself, therefore this is + not an issue.</p> + <p>The executable name (also known as <c>argv[0]</c>) + is not to be specified in this list. The proper executable name + is automatically used as <c>argv[0]</c>, where applicable.</p> + <p>If you explicitly want to set the + program name in the argument vector, option <c>arg0</c> + can be used.</p> + </item> + <tag><c>{arg0, string() | binary()}</c></tag> + <item> + <p>Only valid for <c>{spawn_executable, <anno>FileName</anno>}</c> + and explicitly specifies the program name argument when + running an executable. This can in some circumstances, + on some OSs, be desirable. How the program + responds to this is highly system-dependent and no specific + effect is guaranteed.</p> + </item> <tag><c>exit_status</c></tag> <item> <p>Only valid for <c>{spawn, <anno>Command</anno>}</c>, where <c><anno>Command</anno></c> refers to an external program, and - for <c>{spawn_executable, <anno>FileName</anno>}</c>.</p> + for <c>{spawn_executable, <anno>FileName</anno>}</c>.</p> <p>When the external process connected to the port exits, a message of the form <c>{Port,{exit_status,Status}}</c> is sent to the connected process, where <c>Status</c> is the exit status of the external process. If the program aborts on Unix, the same convention is used as the shells do (that is, 128+signal).</p> - <p>If option <c>eof</c> is also given, the messages <c>eof</c> + <p>If option <c>eof</c> is specified also, the messages <c>eof</c> and <c>exit_status</c> appear in an unspecified order.</p> <p>If the port program closes its <c>stdout</c> without exiting, option <c>exit_status</c> does not work.</p> @@ -3518,7 +3610,7 @@ os_prompt% </pre> <tag><c>use_stdio</c></tag> <item> <p>Only valid for <c>{spawn, <anno>Command</anno>}</c> and - <c>{spawn_executable, <anno>FileName</anno>}</c>. It + <c>{spawn_executable, <anno>FileName</anno>}</c>. It allows the standard input and output (file descriptors 0 and 1) of the spawned (Unix) process for communication with Erlang.</p> @@ -3538,14 +3630,14 @@ os_prompt% </pre> <tag><c>overlapped_io</c></tag> <item> <p>Affects ports to external programs on Windows only. The - standard input and standard output handles of the port program - are, if this option is supplied, opened with flag - <c>FILE_FLAG_OVERLAPPED</c>, so that the port program can - (and must) do - overlapped I/O on its standard handles. This is not normally - the case for simple port programs, but an option of value for the - experienced Windows programmer. <em>On all other platforms, this - option is silently discarded.</em></p> + standard input and standard output handles of the port program + are, if this option is supplied, opened with flag + <c>FILE_FLAG_OVERLAPPED</c>, so that the port program can + (and must) do + overlapped I/O on its standard handles. This is not normally + the case for simple port programs, but an option of value for the + experienced Windows programmer. <em>On all other platforms, this + option is silently discarded.</em></p> </item> <tag><c>in</c></tag> <item> @@ -3570,27 +3662,28 @@ os_prompt% </pre> <tag><c>hide</c></tag> <item> <p>When running on Windows, suppresses creation of a new - console window when spawning the port program. - (This option has no effect on other platforms.)</p> + console window when spawning the port program. + (This option has no effect on other platforms.)</p> </item> <tag><c>{parallelism, Boolean}</c></tag> <item> - <marker id="open_port_parallelism"></marker> + <marker id="open_port_parallelism"></marker> <p>Sets scheduler hint for port parallelism. If set to - <c>true</c>, the Virtual Machine schedules port tasks; - when doing so, it improves parallelism in the system. If set - to <c>false</c>, the Virtual Machine tries to - perform port tasks immediately, improving latency at the - expense of parallelism. The default can be set at system startup - by passing command-line argument - <seealso marker="erl#+spp">+spp</seealso> to <c>erl(1)</c>.</p> + <c>true</c>, the virtual machine schedules port tasks; + when doing so, it improves parallelism in the system. If set + to <c>false</c>, the virtual machine tries to + perform port tasks immediately, improving latency at the + expense of parallelism. The default can be set at system startup + by passing command-line argument + <seealso marker="erl#+spp"><c>+spp</c></seealso> to + <c>erl(1)</c>.</p> </item> </taglist> <p>Default is <c>stream</c> for all port types and <c>use_stdio</c> for spawned ports.</p> - <p>Failure: If the port cannot be opened, the exit reason is - <c>badarg</c>, <c>system_limit</c>, or the POSIX error code that - most closely describes the error, or <c>einval</c> if no POSIX + <p>Failure: if the port cannot be opened, the exit reason is + <c>badarg</c>, <c>system_limit</c>, or the POSIX error code that + most closely describes the error, or <c>einval</c> if no POSIX code is appropriate:</p> <taglist> <tag><c>badarg</c></tag> @@ -3616,11 +3709,11 @@ os_prompt% </pre> <item>Full file table (for the entire OS). </item> <tag><c>eacces</c></tag> - <item><c>Command</c> given in <c>{spawn_executable, Command}</c> + <item><c>Command</c> specified in <c>{spawn_executable, Command}</c> does not point out an executable file. </item> <tag><c>enoent</c></tag> - <item><c><anno>FileName</anno></c> given in + <item><c><anno>FileName</anno></c> specified in <c>{spawn_executable, <anno>FileName</anno>}</c> does not point out an existing file. </item> @@ -3630,13 +3723,12 @@ os_prompt% </pre> errors arising when sending messages to it are reported to the owning process using signals of the form <c>{'EXIT', Port, PosixCode}</c>. For the possible values of - <c>PosixCode</c>, see the - <seealso marker="kernel:file">file(3)</seealso> - manual page in <c>Kernel</c>.</p> - <p>The maximum number of ports that can be open at the same + <c>PosixCode</c>, see + <seealso marker="kernel:file"><c>kernel:file(3)</c></seealso>.</p> + <p>The maximum number of ports that can be open at the same time can be configured by passing command-line flag - <seealso marker="erl#max_ports"><c>+Q</c></seealso> to - <c>erl(1)</c>.</p> + <seealso marker="erl#max_ports"><c>+Q</c></seealso> to + <c>erl(1)</c>.</p> </desc> </func> @@ -3651,7 +3743,7 @@ os_prompt% </pre> The function returns a hash value for <c><anno>Term</anno></c> within the range <c>1..<anno>Range</anno></c>. The maximum value for - <c><anno>Range</anno></c> is 2^32.</p> + <c><anno>Range</anno></c> is 2^32.</p> <p>This BIF can be used instead of the old deprecated BIF <c>erlang:hash/2</c>, as it calculates better hashes for all data types, but consider using <c>phash2/1,2</c> instead.</p> @@ -3669,9 +3761,9 @@ os_prompt% </pre> the same Erlang term regardless of machine architecture and <c>ERTS</c> version (the BIF was introduced in <c>ERTS</c> 5.2). The function returns a hash value for - <c><anno>Term</anno></c> within the range - <c>0..<anno>Range</anno>-1</c>. The maximum value for - <c><anno>Range</anno></c> is 2^32. When without argument + <c><anno>Term</anno></c> within the range + <c>0..<anno>Range</anno>-1</c>. The maximum value for + <c><anno>Range</anno></c> is 2^32. When without argument <c><anno>Range</anno></c>, a value in the range 0..2^27-1 is returned.</p> <p>This BIF is always to be used for hashing terms. It @@ -3691,66 +3783,109 @@ os_prompt% </pre> representation of <c><anno>Pid</anno></c>.</p> <warning> <p>This BIF is intended for debugging and is not to be used - in application programs.</p> + in application programs.</p> </warning> </desc> </func> <func> + <name name="port_call" arity="3"/> + <fsummary>Perform a synchronous call to a port with term data.</fsummary> + <desc> + <p>Performs a synchronous call to a port. The meaning of + <c><anno>Operation</anno></c> and <c><anno>Data</anno></c> + depends on the port, that is, + on the port driver. Not all port drivers support this feature.</p> + <p><c><anno>Port</anno></c> is a port identifier, + referring to a driver.</p> + <p><c><anno>Operation</anno></c> is an integer, which is passed on to + the driver.</p> + <p><c><anno>Data</anno></c> is any Erlang term. This data is converted + to binary term format and sent to the port.</p> + <p>Returns a term from the driver. The meaning of the returned + data also depends on the port driver.</p> + <p>Failures:</p> + <taglist> + <tag><c>badarg</c></tag> + <item> + If <c><anno>Port</anno></c> is not an identifier of an open port, + or the registered name of an open port. If the calling + process was previously linked to the closed port, + identified by <c><anno>Port</anno></c>, the exit signal + from the port is guaranteed to be delivered before this + <c>badarg</c> exception occurs. + </item> + <tag><c>badarg</c></tag> + <item> + If <c><anno>Operation</anno></c> does not fit in a 32-bit integer. + </item> + <tag><c>badarg</c></tag> + <item> + If the port driver does not support synchronous control operations. + </item> + <tag><c>badarg</c></tag> + <item> + If the port driver so decides for any reason (probably + something wrong with <c><anno>Operation</anno></c> + or <c><anno>Data</anno></c>). + </item> + </taglist> + </desc> + </func> + + <func> <name name="port_close" arity="1"/> - <fsummary>Closes an open port.</fsummary> - <desc> - <p>Closes an open port. Roughly the same as - <c><anno>Port</anno> ! {self(), close}</c> except for the error behavior - (see the following), being synchronous, and that the port does - <em>not</em> reply with <c>{Port, closed}</c>. Any process can - close a port with <c>port_close/1</c>, not only the port owner - (the connected process). If the calling process is linked to + <fsummary>Close an open port.</fsummary> + <desc> + <p>Closes an open port. Roughly the same as <c><anno>Port</anno> ! + {self(), close}</c> except for the error behavior + (see below), being synchronous, and that the port does + <em>not</em> reply with <c>{Port, closed}</c>. Any process can + close a port with <c>port_close/1</c>, not only the port owner + (the connected process). If the calling process is linked to the port identified by <c><anno>Port</anno></c>, the exit - signal from the port is guaranteed to be delivered before - <c>port_close/1</c> returns.</p> + signal from the port is guaranteed to be delivered before + <c>port_close/1</c> returns.</p> <p>For comparison: <c><anno>Port</anno> ! {self(), close}</c> - only fails with <c>badarg</c> if <c><anno>Port</anno></c> does - not refer to a port or a process. If <c><anno>Port</anno></c> - is a closed port, nothing happens. If <c><anno>Port</anno></c> + only fails with <c>badarg</c> if <c><anno>Port</anno></c> does + not refer to a port or a process. If <c><anno>Port</anno></c> + is a closed port, nothing happens. If <c><anno>Port</anno></c> is an open port and the calling process is the port owner, - the port replies with <c>{Port, closed}</c> when all buffers - have been flushed and the port really closes. If the calling - process is not the port owner, the <em>port owner</em> fails - with <c>badsig</c>.</p> + the port replies with <c>{Port, closed}</c> when all buffers + have been flushed and the port really closes. If the calling + process is not the port owner, the <em>port owner</em> fails + with <c>badsig</c>.</p> <p>Notice that any process can close a port using <c><anno>Port</anno> ! {PortOwner, close}</c> as if it itself was the port owner, but the reply always goes to the port owner.</p> - <p>As from OTP R16, <c><anno>Port</anno> ! {PortOwner, close}</c> is truly - asynchronous. Notice that this operation has always been - documented as an asynchronous operation, while the underlying - implementation has been synchronous. <c>port_close/1</c> is - however still fully synchronous. This because of its error - behavior.</p> - <p>Failure: <c>badarg</c> if <c><anno>Port</anno></c> is not an identifier - of an open port, or the registered name of an open port. - If the calling process was previously linked to the closed - port, identified by <c><anno>Port</anno></c>, the exit - signal from the port is guaranteed to be delivered before - this <c>badarg</c> exception occurs.</p> + <p>As from Erlang/OTP R16, + <c><anno>Port</anno> ! {PortOwner, close}</c> is truly + asynchronous. Notice that this operation has always been + documented as an asynchronous operation, while the underlying + implementation has been synchronous. <c>port_close/1</c> is + however still fully synchronous because of its error behavior.</p> + <p>Failure: <c>badarg</c> if <c><anno>Port</anno></c> is not an + identifier of an open port, or the registered name of an open port. + If the calling process was previously linked to the closed + port, identified by <c><anno>Port</anno></c>, the exit + signal from the port is guaranteed to be delivered before + this <c>badarg</c> exception occurs.</p> </desc> </func> <func> <name name="port_command" arity="2"/> - <fsummary>Sends data to a port.</fsummary> + <fsummary>Send data to a port.</fsummary> <desc> <p>Sends data to a port. Same as - <c><anno>Port</anno> ! {PortOwner, {command, Data}}</c> except - for the error - behavior and being synchronous (see the following). Any process - can send data to a port with <c>port_command/2</c>, not only the - port owner (the connected process).</p> - <p>For comparison: <c><anno>Port</anno> ! {PortOwner, {command, Data}}</c> - only fails with <c>badarg</c> if <c><anno>Port</anno></c> - does not refer to a port or a process. If - <c><anno>Port</anno></c> is a closed port, the data message - disappears + <c><anno>Port</anno> ! {PortOwner, {command, Data}}</c> except for + the error behavior and being synchronous (see below). Any process + can send data to a port with <c>port_command/2</c>, not only the + port owner (the connected process).</p> + <p>For comparison: <c><anno>Port</anno> ! {PortOwner, {command, + Data}}</c> only fails with <c>badarg</c> if <c><anno>Port</anno></c> + does not refer to a port or a process. If <c><anno>Port</anno></c> is + a closed port, the data message disappears without a sound. If <c><anno>Port</anno></c> is open and the calling process is not the port owner, the <em>port owner</em> fails with <c>badsig</c>. The port owner fails with <c>badsig</c> @@ -3758,57 +3893,58 @@ os_prompt% </pre> <p>Notice that any process can send to a port using <c><anno>Port</anno> ! {PortOwner, {command, <anno>Data</anno>}}</c> as if it itself was the port owner.</p> - <p>If the port is busy, the calling process is suspended - until the port is not busy any more.</p> - <p>As from OTP-R16, <c><anno>Port</anno> ! {PortOwner, {command, Data}}</c> - is truly asynchronous. Notice that this operation has always been - documented as an asynchronous operation, while the underlying - implementation has been synchronous. <c>port_command/2</c> is - however still fully synchronous. This because of its error - behavior.</p> + <p>If the port is busy, the calling process is suspended + until the port is not busy any more.</p> + <p>As from Erlang/OTP R16, + <c><anno>Port</anno> ! {PortOwner, {command, Data}}</c> + is truly asynchronous. Notice that this operation has always been + documented as an asynchronous operation, while the underlying + implementation has been synchronous. <c>port_command/2</c> is + however still fully synchronous because of its error behavior.</p> <p>Failures:</p> <taglist> <tag><c>badarg</c></tag> <item> - If <c><anno>Port</anno></c> is not an identifier of an open - port, or the registered name of an open port. If the - calling process was previously linked to the closed port, - identified by <c><anno>Port</anno></c>, the exit signal - from the port is guaranteed to be delivered before this - <c>badarg</c> exception occurs. - </item> + <p>If <c><anno>Port</anno></c> is not an identifier of an open + port, or the registered name of an open port. If the + calling process was previously linked to the closed port, + identified by <c><anno>Port</anno></c>, the exit signal + from the port is guaranteed to be delivered before this + <c>badarg</c> exception occurs.</p> + </item> <tag><c>badarg</c></tag> <item> - If <c><anno>Data</anno></c> is an invalid I/O list. - </item> - </taglist> + <p>If <c><anno>Data</anno></c> is an invalid I/O list.</p> + </item> + </taglist> </desc> </func> <func> <name name="port_command" arity="3"/> - <fsummary>Sends data to a port.</fsummary> + <fsummary>Send data to a port.</fsummary> <desc> <p>Sends data to a port. <c>port_command(Port, Data, [])</c> - equals <c>port_command(Port, Data)</c>.</p> - <p>If the port command is aborted, <c>false</c> is returned, - otherwise <c>true</c>.</p> - <p>If the port is busy, the calling process is suspended - until the port is not busy any more.</p> - <p>The following <c><anno>Option</anno></c>s are valid:</p> + equals <c>port_command(Port, Data)</c>.</p> + <p>If the port command is aborted, <c>false</c> is returned, + otherwise <c>true</c>.</p> + <p>If the port is busy, the calling process is suspended + until the port is not busy anymore.</p> + <p><c><anno>Option</anno></c>s:</p> <taglist> <tag><c>force</c></tag> <item>The calling process is not suspended if the port is - busy, instead the port command is forced through. The - call fails with a <c>notsup</c> exception if the - driver of the port does not support this. For more - information, see driver flag - <seealso marker="driver_entry#driver_flags"><![CDATA[ERL_DRV_FLAG_SOFT_BUSY]]></seealso>. + busy, instead the port command is forced through. The + call fails with a <c>notsup</c> exception if the + driver of the port does not support this. For more + information, see driver flag + <seealso marker="driver_entry#driver_flags"> + <c>![CDATA[ERL_DRV_FLAG_SOFT_BUSY]]</c></seealso>. </item> <tag><c>nosuspend</c></tag> <item>The calling process is not suspended if the port is - busy, instead the port command is aborted and - <c>false</c> is returned. + busy, instead the port command is aborted and + <c>false</c> is returned. </item> </taglist> <note> @@ -3818,34 +3954,34 @@ os_prompt% </pre> <taglist> <tag><c>badarg</c></tag> <item> - If <c><anno>Port</anno></c> is not an identifier of an open - port, or the registered name of an open port. If the - calling process was previously linked to the closed port, - identified by <c><anno>Port</anno></c>, the exit signal - from the port is guaranteed to be delivered before this - <c>badarg</c> exception occurs. - </item> + If <c><anno>Port</anno></c> is not an identifier of an open + port, or the registered name of an open port. If the + calling process was previously linked to the closed port, + identified by <c><anno>Port</anno></c>, the exit signal + from the port is guaranteed to be delivered before this + <c>badarg</c> exception occurs. + </item> <tag><c>badarg</c></tag> <item> - If <c><anno>Data</anno></c> is an invalid I/O list. - </item> + If <c><anno>Data</anno></c> is an invalid I/O list. + </item> <tag><c>badarg</c></tag> <item> - If <c><anno>OptionList</anno></c> is an invalid option list. - </item> + If <c><anno>OptionList</anno></c> is an invalid option list. + </item> <tag><c>notsup</c></tag> <item> - If option <c>force</c> has been passed, but the - driver of the port does not allow forcing through - a busy port. - </item> - </taglist> + If option <c>force</c> has been passed, but the + driver of the port does not allow forcing through + a busy port. + </item> + </taglist> </desc> </func> <func> <name name="port_connect" arity="2"/> - <fsummary>Sets the owner of a port.</fsummary> + <fsummary>Set the owner of a port.</fsummary> <desc> <p>Sets the port owner (the connected port) to <c><anno>Pid</anno></c>. Roughly the same as @@ -3853,14 +3989,14 @@ os_prompt% </pre> except for the following:</p> <list type="bulleted"> <item> - <p>The error behavior differs, see the following.</p> + <p>The error behavior differs, see below.</p> </item> <item> <p>The port does <em>not</em> reply with <c>{Port,connected}</c>.</p> </item> <item> - <p><c>port_connect/1</c> is synchronous, see the following.</p> + <p><c>port_connect/1</c> is synchronous, see below.</p> </item> <item> <p>The new port owner gets linked to the port.</p> @@ -3872,7 +4008,7 @@ os_prompt% </pre> <c>port_connect/2</c>.</p> <p>For comparison: <c><anno>Port</anno> ! {self(), {connect, <anno>Pid</anno>}}</c> - only fails with <c>badarg</c> if <c><anno>Port</anno></c> + only fails with <c>badarg</c> if <c><anno>Port</anno></c> does not refer to a port or a process. If <c><anno>Port</anno></c> is a closed port, nothing happens. If <c><anno>Port</anno></c> @@ -3882,40 +4018,39 @@ os_prompt% </pre> the port, while the new is not. If <c><anno>Port</anno></c> is an open port and the calling process is not the port owner, the <em>port owner</em> fails with <c>badsig</c>. The port - owner fails with <c>badsig</c> also if <c><anno>Pid</anno></c> is not an - existing local process identifier.</p> + owner fails with <c>badsig</c> also if <c><anno>Pid</anno></c> is not + an existing local process identifier.</p> <p>Notice that any process can set the port owner using <c><anno>Port</anno> ! {PortOwner, {connect, <anno>Pid</anno>}}</c> as if it itself was the port owner, but the reply always goes to the port owner.</p> - <p>As from OTP-R16, - <c><anno>Port</anno> ! {PortOwner, {connect, <anno>Pid</anno>}}</c> is - truly asynchronous. Notice that this operation has always been - documented as an asynchronous operation, while the underlying - implementation has been synchronous. <c>port_connect/2</c> is - however still fully synchronous. This because of its error - behavior.</p> + <p>As from Erlang/OTP R16, + <c><anno>Port</anno> ! {PortOwner, {connect, <anno>Pid</anno>}}</c> + is truly asynchronous. Notice that this operation has always been + documented as an asynchronous operation, while the underlying + implementation has been synchronous. <c>port_connect/2</c> is + however still fully synchronous because of its error behavior.</p> <p>Failures:</p> <taglist> <tag><c>badarg</c></tag> <item> - If <c><anno>Port</anno></c> is not an identifier of an open port, or - the registered name of an open port. If the calling - process was previously linked to the closed port, - identified by <c><anno>Port</anno></c>, the exit signal - from the port is guaranteed to be delivered before this - <c>badarg</c> exception occurs. - </item> + If <c><anno>Port</anno></c> is not an identifier of an open port, + or the registered name of an open port. If the calling + process was previously linked to the closed port, + identified by <c><anno>Port</anno></c>, the exit signal + from the port is guaranteed to be delivered before this + <c>badarg</c> exception occurs. + </item> <tag><c>badarg</c></tag> - <item>If process identified by <c>Pid</c> is not an existing - local process.</item> - </taglist> + <item>If the process identified by <c>Pid</c> is not an existing + local process.</item> + </taglist> </desc> </func> <func> <name name="port_control" arity="3"/> - <fsummary>Performs a synchronous control operation on a port.</fsummary> + <fsummary>Perform a synchronous control operation on a port.</fsummary> <desc> <p>Performs a synchronous control operation on a port. The meaning of <c><anno>Operation</anno></c> and @@ -3929,71 +4064,24 @@ os_prompt% </pre> <taglist> <tag><c>badarg</c></tag> <item> - If <c><anno>Port</anno></c> is not an open port or the registered - name of an open port. - </item> + If <c><anno>Port</anno></c> is not an open port or the registered + name of an open port. + </item> <tag><c>badarg</c></tag> <item> - If <c><anno>Operation</anno></c> cannot fit in a 32-bit integer. - </item> + If <c><anno>Operation</anno></c> cannot fit in a 32-bit integer. + </item> <tag><c>badarg</c></tag> <item> - If the port driver does not support synchronous control - operations. - </item> + If the port driver does not support synchronous control operations. + </item> <tag><c>badarg</c></tag> <item> - If the port driver so decides for any reason (probably + If the port driver so decides for any reason (probably something wrong with <c><anno>Operation</anno></c> or <c><anno>Data</anno></c>). - </item> - </taglist> - </desc> - </func> - - <func> - <name name="port_call" arity="3"/> - <fsummary>Performs a synchronous call to a port with term data.</fsummary> - <desc> - <p>Performs a synchronous call to a port. The meaning of - <c><anno>Operation</anno></c> and <c><anno>Data</anno></c> - depends on the port, that is, - on the port driver. Not all port drivers support this feature.</p> - <p><c><anno>Port</anno></c> is a port identifier, - referring to a driver.</p> - <p><c><anno>Operation</anno></c> is an integer, which is passed on to - the driver.</p> - <p><c><anno>Data</anno></c> is any Erlang term. This data is converted - to binary term format and sent to the port.</p> - <p>Returns a term from the driver. The meaning of the returned - data also depends on the port driver.</p> - <p>Failures:</p> - <taglist> - <tag><c>badarg</c></tag> - <item> - If <c><anno>Port</anno></c> is not an identifier of an open port, - or the registered name of an open port. If the calling - process was previously linked to the closed port, - identified by <c><anno>Port</anno></c>, the exit signal - from the port is guaranteed to be delivered before this - <c>badarg</c> exception occurs. - </item> - <tag><c>badarg</c></tag> - <item> - If <c><anno>Operation</anno></c> does not fit in a 32-bit integer. - </item> - <tag><c>badarg</c></tag> - <item> - If the port driver does not support synchronous control - operations. - </item> - <tag><c>badarg</c></tag> - <item> - If the port driver so decides for any reason (probably - something wrong with <c><anno>Operation</anno></c> - or <c><anno>Data</anno></c>). - </item> - </taglist> + </item> + </taglist> </desc> </func> @@ -4005,11 +4093,11 @@ os_prompt% </pre> <c><anno>Port</anno></c>, or <c>undefined</c> if the port is not open. The order of the tuples is undefined, and all the tuples are not mandatory. - If the port is closed and the calling process - was previously linked to the port, the exit signal from the - port is guaranteed to be delivered before <c>port_info/1</c> - returns <c>undefined</c>.</p> - <p>The result contains information about the following + If the port is closed and the calling process + was previously linked to the port, the exit signal from the + port is guaranteed to be delivered before <c>port_info/1</c> + returns <c>undefined</c>.</p> + <p>The result contains information about the following <c>Item</c>s:</p> <list type="bulleted"> <item><c>registered_name</c> (if the port has a registered @@ -4022,9 +4110,9 @@ os_prompt% </pre> <item><c>output</c></item> </list> <p>For more information about the different <c>Item</c>s, see - <seealso marker="#port_info/2">port_info/2</seealso>.</p> + <seealso marker="#port_info/2"><c>port_info/2</c></seealso>.</p> <p>Failure: <c>badarg</c> if <c>Port</c> is not a local port - identifier, or an atom.</p> + identifier, or an atom.</p> </desc> </func> @@ -4032,15 +4120,15 @@ os_prompt% </pre> <name name="port_info" arity="2" clause_i="1"/> <fsummary>Information about the connected process of a port.</fsummary> <desc> - <p><c><anno>Pid</anno></c> is the process identifier of the process - connected to the port.</p> - <p>If the port identified by <c><anno>Port</anno></c> is not open, - <c>undefined</c> is returned. If the port is closed and the - calling process was previously linked to the port, the exit - signal from the port is guaranteed to be delivered before - <c>port_info/2</c> returns <c>undefined</c>.</p> + <p><c><anno>Pid</anno></c> is the process identifier of the process + connected to the port.</p> + <p>If the port identified by <c><anno>Port</anno></c> is not open, + <c>undefined</c> is returned. If the port is closed and the + calling process was previously linked to the port, the exit + signal from the port is guaranteed to be delivered before + <c>port_info/2</c> returns <c>undefined</c>.</p> <p>Failure: <c>badarg</c> if <c><anno>Port</anno></c> is not a local - port identifier, or an atom.</p> + port identifier, or an atom.</p> </desc> </func> @@ -4048,15 +4136,15 @@ os_prompt% </pre> <name name="port_info" arity="2" clause_i="2"/> <fsummary>Information about the internal index of a port.</fsummary> <desc> - <p><c><anno>Index</anno></c> is the internal index of the port. This - index can be used to separate ports.</p> - <p>If the port identified by <c><anno>Port</anno></c> is not open, - <c>undefined</c> is returned. If the port is closed and the - calling process was previously linked to the port, the exit - signal from the port is guaranteed to be delivered before - <c>port_info/2</c> returns <c>undefined</c>.</p> + <p><c><anno>Index</anno></c> is the internal index of the port. This + index can be used to separate ports.</p> + <p>If the port identified by <c><anno>Port</anno></c> is not open, + <c>undefined</c> is returned. If the port is closed and the + calling process was previously linked to the port, the exit + signal from the port is guaranteed to be delivered before + <c>port_info/2</c> returns <c>undefined</c>.</p> <p>Failure: <c>badarg</c> if <c><anno>Port</anno></c> is not a local - port identifier, or an atom.</p> + port identifier, or an atom.</p> </desc> </func> @@ -4064,15 +4152,15 @@ os_prompt% </pre> <name name="port_info" arity="2" clause_i="3"/> <fsummary>Information about the input of a port.</fsummary> <desc> - <p><c><anno>Bytes</anno></c> is the total number of bytes - read from the port.</p> - <p>If the port identified by <c><anno>Port</anno></c> is not open, - <c>undefined</c> is returned. If the port is closed and the - calling process was previously linked to the port, the exit - signal from the port is guaranteed to be delivered before - <c>port_info/2</c> returns <c>undefined</c>.</p> + <p><c><anno>Bytes</anno></c> is the total number of bytes + read from the port.</p> + <p>If the port identified by <c><anno>Port</anno></c> is not open, + <c>undefined</c> is returned. If the port is closed and the + calling process was previously linked to the port, the exit + signal from the port is guaranteed to be delivered before + <c>port_info/2</c> returns <c>undefined</c>.</p> <p>Failure: <c>badarg</c> if <c><anno>Port</anno></c> is not a local - port identifier, or an atom.</p> + port identifier, or an atom.</p> </desc> </func> @@ -4080,15 +4168,15 @@ os_prompt% </pre> <name name="port_info" arity="2" clause_i="4"/> <fsummary>Information about the links of a port.</fsummary> <desc> - <p><c><anno>Pids</anno></c> is a list of the process identifiers - of the processes that the port is linked to.</p> - <p>If the port identified by <c><anno>Port</anno></c> is not open, - <c>undefined</c> is returned. If the port is closed and the - calling process was previously linked to the port, the exit - signal from the port is guaranteed to be delivered before - <c>port_info/2</c> returns <c>undefined</c>.</p> + <p><c><anno>Pids</anno></c> is a list of the process identifiers + of the processes that the port is linked to.</p> + <p>If the port identified by <c><anno>Port</anno></c> is not open, + <c>undefined</c> is returned. If the port is closed and the + calling process was previously linked to the port, the exit + signal from the port is guaranteed to be delivered before + <c>port_info/2</c> returns <c>undefined</c>.</p> <p>Failure: <c>badarg</c> if <c><anno>Port</anno></c> is not a local - port identifier, or an atom.</p> + port identifier, or an atom.</p> </desc> </func> @@ -4096,7 +4184,7 @@ os_prompt% </pre> <name name="port_info" arity="2" clause_i="5"/> <fsummary>Information about the locking of a port.</fsummary> <desc> - <p><c><anno>Locking</anno></c> is one of the following:</p> + <p><c><anno>Locking</anno></c> is one of the following:</p> <list type="bulleted"> <item><c>false</c> (emulator without SMP support)</item> <item><c>port_level</c> (port-specific locking)</item> @@ -4104,13 +4192,13 @@ os_prompt% </pre> </list> <p>Notice that these results are highly implementation-specific and can change in a future release.</p> - <p>If the port identified by <c><anno>Port</anno></c> is not open, - <c>undefined</c> is returned. If the port is closed and the - calling process was previously linked to the port, the exit - signal from the port is guaranteed to be delivered before - <c>port_info/2</c> returns <c>undefined</c>.</p> + <p>If the port identified by <c><anno>Port</anno></c> is not open, + <c>undefined</c> is returned. If the port is closed and the + calling process was previously linked to the port, the exit + signal from the port is guaranteed to be delivered before + <c>port_info/2</c> returns <c>undefined</c>.</p> <p>Failure: <c>badarg</c> if <c><anno>Port</anno></c> is not a local - port identifier, or an atom.</p> + port identifier, or an atom.</p> </desc> </func> @@ -4118,17 +4206,17 @@ os_prompt% </pre> <name name="port_info" arity="2" clause_i="6"/> <fsummary>Information about the memory size of a port.</fsummary> <desc> - <p><c><anno>Bytes</anno></c> is the total number of - bytes allocated for this port by the runtime system. The - port itself can have allocated memory that is not - included in <c><anno>Bytes</anno></c>.</p> - <p>If the port identified by <c><anno>Port</anno></c> is not open, - <c>undefined</c> is returned. If the port is closed and the - calling process was previously linked to the port, the exit - signal from the port is guaranteed to be delivered before - <c>port_info/2</c> returns <c>undefined</c>.</p> + <p><c><anno>Bytes</anno></c> is the total number of + bytes allocated for this port by the runtime system. The + port itself can have allocated memory that is not + included in <c><anno>Bytes</anno></c>.</p> + <p>If the port identified by <c><anno>Port</anno></c> is not open, + <c>undefined</c> is returned. If the port is closed and the + calling process was previously linked to the port, the exit + signal from the port is guaranteed to be delivered before + <c>port_info/2</c> returns <c>undefined</c>.</p> <p>Failure: <c>badarg</c> if <c><anno>Port</anno></c> is not a local - port identifier, or an atom.</p> + port identifier, or an atom.</p> </desc> </func> @@ -4136,15 +4224,15 @@ os_prompt% </pre> <name name="port_info" arity="2" clause_i="7"/> <fsummary>Information about the monitors of a port.</fsummary> <desc> - <p><c><anno>Monitors</anno></c> represent processes that this port - monitors.</p> - <p>If the port identified by <c><anno>Port</anno></c> is not open, - <c>undefined</c> is returned. If the port is closed and the - calling process was previously linked to the port, the exit - signal from the port is guaranteed to be delivered before - <c>port_info/2</c> returns <c>undefined</c>.</p> + <p><c><anno>Monitors</anno></c> represent processes monitored by + this port.</p> + <p>If the port identified by <c><anno>Port</anno></c> is not open, + <c>undefined</c> is returned. If the port is closed and the + calling process was previously linked to the port, the exit + signal from the port is guaranteed to be delivered before + <c>port_info/2</c> returns <c>undefined</c>.</p> <p>Failure: <c>badarg</c> if <c><anno>Port</anno></c> is not a local - port identifier, or an atom.</p> + port identifier, or an atom.</p> </desc> </func> @@ -4168,15 +4256,15 @@ os_prompt% </pre> <name name="port_info" arity="2" clause_i="9"/> <fsummary>Information about the name of a port.</fsummary> <desc> - <p><c><anno>Name</anno></c> is the command name set by - <seealso marker="#open_port/2">open_port/2</seealso>.</p> - <p>If the port identified by <c><anno>Port</anno></c> is not open, - <c>undefined</c> is returned. If the port is closed and the - calling process was previously linked to the port, the exit - signal from the port is guaranteed to be delivered before - <c>port_info/2</c> returns <c>undefined</c>.</p> + <p><c><anno>Name</anno></c> is the command name set by + <seealso marker="#open_port/2"><c>open_port/2</c></seealso>.</p> + <p>If the port identified by <c><anno>Port</anno></c> is not open, + <c>undefined</c> is returned. If the port is closed and the + calling process was previously linked to the port, the exit + signal from the port is guaranteed to be delivered before + <c>port_info/2</c> returns <c>undefined</c>.</p> <p>Failure: <c>badarg</c> if <c><anno>Port</anno></c> is not a local - port identifier, or an atom.</p> + port identifier, or an atom.</p> </desc> </func> @@ -4184,18 +4272,18 @@ os_prompt% </pre> <name name="port_info" arity="2" clause_i="10"/> <fsummary>Information about the OS pid of a port.</fsummary> <desc> - <p><c><anno>OsPid</anno></c> is the process identifier (or equivalent) - of an OS process created with - <seealso marker="#open_port/2">open_port({spawn | spawn_executable, - Command}, Options)</seealso>. If the port is not the result of spawning - an OS process, the value is <c>undefined</c>.</p> - <p>If the port identified by <c><anno>Port</anno></c> is not open, - <c>undefined</c> is returned. If the port is closed and the - calling process was previously linked to the port, the exit - signal from the port is guaranteed to be delivered before - <c>port_info/2</c> returns <c>undefined</c>.</p> + <p><c><anno>OsPid</anno></c> is the process identifier (or equivalent) + of an OS process created with + <seealso marker="#open_port/2"><c>open_port({spawn | spawn_executable, + Command}, Options)</c></seealso>. If the port is not the result of + spawning an OS process, the value is <c>undefined</c>.</p> + <p>If the port identified by <c><anno>Port</anno></c> is not open, + <c>undefined</c> is returned. If the port is closed and the + calling process was previously linked to the port, the exit + signal from the port is guaranteed to be delivered before + <c>port_info/2</c> returns <c>undefined</c>.</p> <p>Failure: <c>badarg</c> if <c><anno>Port</anno></c> is not a local - port identifier, or an atom.</p> + port identifier, or an atom.</p> </desc> </func> @@ -4203,18 +4291,18 @@ os_prompt% </pre> <name name="port_info" arity="2" clause_i="11"/> <fsummary>Information about the output of a port.</fsummary> <desc> - <p><c><anno>Bytes</anno></c> is the total number of bytes written - to the port from Erlang processes using - <seealso marker="#port_command/2">port_command/2</seealso>, - <seealso marker="#port_command/3">port_command/3</seealso>, - or <c><anno>Port</anno> ! {Owner, {command, Data}</c>.</p> - <p>If the port identified by <c><anno>Port</anno></c> is not open, - <c>undefined</c> is returned. If the port is closed and the - calling process was previously linked to the port, the exit - signal from the port is guaranteed to be delivered before - <c>port_info/2</c> returns <c>undefined</c>.</p> + <p><c><anno>Bytes</anno></c> is the total number of bytes written + to the port from Erlang processes using + <seealso marker="#port_command/2"><c>port_command/2</c></seealso>, + <seealso marker="#port_command/3"><c>port_command/3</c></seealso>, + or <c><anno>Port</anno> ! {Owner, {command, Data}</c>.</p> + <p>If the port identified by <c><anno>Port</anno></c> is not open, + <c>undefined</c> is returned. If the port is closed and the + calling process was previously linked to the port, the exit + signal from the port is guaranteed to be delivered before + <c>port_info/2</c> returns <c>undefined</c>.</p> <p>Failure: <c>badarg</c> if <c><anno>Port</anno></c> is not a local - port identifier, or an atom.</p> + port identifier, or an atom.</p> </desc> </func> @@ -4222,10 +4310,10 @@ os_prompt% </pre> <name name="port_info" arity="2" clause_i="12"/> <fsummary>Information about the parallelism hint of a port.</fsummary> <desc> - <p><c><anno>Boolean</anno></c> corresponds to the port parallelism - hint being used by this port. For more information, see option - <seealso marker="#open_port_parallelism">parallelism</seealso> - of <seealso marker="#open_port/2">open_port/2</seealso>.</p> + <p><c><anno>Boolean</anno></c> corresponds to the port parallelism + hint used by this port. For more information, see option + <seealso marker="#open_port_parallelism"><c>parallelism</c></seealso> + of <seealso marker="#open_port/2"><c>open_port/2</c></seealso>.</p> </desc> </func> @@ -4233,16 +4321,16 @@ os_prompt% </pre> <name name="port_info" arity="2" clause_i="13"/> <fsummary>Information about the queue size of a port.</fsummary> <desc> - <p><c><anno>Bytes</anno></c> is the total number - of bytes queued by the port using the <c>ERTS</c> driver queue - implementation.</p> - <p>If the port identified by <c><anno>Port</anno></c> is not open, - <c>undefined</c> is returned. If the port is closed and the - calling process was previously linked to the port, the exit - signal from the port is guaranteed to be delivered before - <c>port_info/2</c> returns <c>undefined</c>.</p> + <p><c><anno>Bytes</anno></c> is the total number + of bytes queued by the port using the <c>ERTS</c> driver queue + implementation.</p> + <p>If the port identified by <c><anno>Port</anno></c> is not open, + <c>undefined</c> is returned. If the port is closed and the + calling process was previously linked to the port, the exit + signal from the port is guaranteed to be delivered before + <c>port_info/2</c> returns <c>undefined</c>.</p> <p>Failure: <c>badarg</c> if <c><anno>Port</anno></c> is not a local - port identifier, or an atom.</p> + port identifier, or an atom.</p> </desc> </func> @@ -4250,15 +4338,16 @@ os_prompt% </pre> <name name="port_info" arity="2" clause_i="14"/> <fsummary>Information about the registered name of a port.</fsummary> <desc> - <p><c><anno>RegisteredName</anno></c> is the registered name of - the port. If the port has no registered name, <c>[]</c> is returned.</p> - <p>If the port identified by <c><anno>Port</anno></c> is not open, - <c>undefined</c> is returned. If the port is closed and the - calling process was previously linked to the port, the exit - signal from the port is guaranteed to be delivered before - <c>port_info/2</c> returns <c>undefined</c>.</p> + <p><c><anno>RegisteredName</anno></c> is the registered name of + the port. If the port has no registered name, <c>[]</c> is + returned.</p> + <p>If the port identified by <c><anno>Port</anno></c> is not open, + <c>undefined</c> is returned. If the port is closed and the + calling process was previously linked to the port, the exit + signal from the port is guaranteed to be delivered before + <c>port_info/2</c> returns <c>undefined</c>.</p> <p>Failure: <c>badarg</c> if <c><anno>Port</anno></c> is not a local - port identifier, or an atom.</p> + port identifier, or an atom.</p> </desc> </func> @@ -4270,24 +4359,24 @@ os_prompt% </pre> representation of the port identifier <c><anno>Port</anno></c>.</p> <warning> <p>This BIF is intended for debugging. It is not to be used - in application programs.</p> + in application programs.</p> </warning> </desc> </func> <func> <name name="ports" arity="0"/> - <fsummary>Lists all existing ports.</fsummary> + <fsummary>List all existing ports.</fsummary> <desc> - <p>Returns a list of port identifiers corresponding to all the - ports existing on the local node.</p> - <p>Notice that an exiting port exists, but is not open.</p> + <p>Returns a list of port identifiers corresponding to all the + ports existing on the local node.</p> + <p>Notice that an exiting port exists, but is not open.</p> </desc> </func> <func> <name name="pre_loaded" arity="0"/> - <fsummary>Lists all pre-loaded modules.</fsummary> + <fsummary>List all preloaded modules.</fsummary> <desc> <p>Returns a list of Erlang modules that are preloaded in the system. As all loading of code is done through the file @@ -4298,12 +4387,13 @@ os_prompt% </pre> <func> <name name="process_display" arity="2"/> - <fsummary>Writes information about a local process on standard error.</fsummary> + <fsummary>Write information about a local process on standard error. + </fsummary> <desc> <p>Writes information about the local process <c><anno>Pid</anno></c> on standard error. The only allowed value for the atom - <c><anno>Type</anno></c> is <c>backtrace</c>, which shows the contents of - the call stack, including information about the call chain, with + <c><anno>Type</anno></c> is <c>backtrace</c>, which shows the contents + of the call stack, including information about the call chain, with the current function printed first. The format of the output is not further defined.</p> </desc> @@ -4311,7 +4401,7 @@ os_prompt% </pre> <func> <name name="process_flag" arity="2" clause_i="1"/> - <fsummary>Sets process flag <c>trap_exit</c> for the calling process.</fsummary> + <fsummary>Set process flag trap_exit for the calling process.</fsummary> <desc> <p>When <c>trap_exit</c> is set to <c>true</c>, exit signals arriving to a process are converted to <c>{'EXIT', From, Reason}</c> @@ -4322,13 +4412,14 @@ os_prompt% </pre> linked processes. Application processes are normally not to trap exits.</p> <p>Returns the old value of the flag.</p> - <p>See also <seealso marker="#exit/2">exit/2</seealso>.</p> + <p>See also <seealso marker="#exit/2"><c>exit/2</c></seealso>.</p> </desc> </func> <func> <name name="process_flag" arity="2" clause_i="2"/> - <fsummary>Sets process flag <c>error_handler</c> for the calling process.</fsummary> + <fsummary>Set process flag error_handler for the calling process. + </fsummary> <desc> <p>Used by a process to redefine the error handler for undefined function calls and undefined registered @@ -4342,7 +4433,8 @@ os_prompt% </pre> <marker id="process_flag_min_heap_size"/> <func> <name name="process_flag" arity="2" clause_i="3"/> - <fsummary>Sets process flag <c>min_heap_size</c> for the calling process.</fsummary> + <fsummary>Set process flag min_heap_size for the calling process. + </fsummary> <desc> <p>Changes the minimum heap size for the calling process.</p> <p>Returns the old value of the flag.</p> @@ -4351,90 +4443,79 @@ os_prompt% </pre> <func> <name name="process_flag" arity="2" clause_i="4"/> - <fsummary>Sets process flag <c>min_bin_vheap_size</c> for the calling process.</fsummary> + <fsummary>Set process flag min_bin_vheap_size for the calling process. + </fsummary> <desc> <p>Changes the minimum binary virtual heap size for the calling process.</p> <p>Returns the old value of the flag.</p> </desc> </func> + <marker id="process_flag_max_heap_size"/> <func> <name name="process_flag" arity="2" clause_i="5"/> - <fsummary>Sets process flag <c>max_heap_size</c> for the calling process.</fsummary> + <fsummary>Set process flag max_heap_size for the calling process. + </fsummary> <type name="max_heap_size"/> <desc> - <p> - This flag sets the maximum heap size for the calling process. + <p>This flag sets the maximum heap size for the calling process. If <c><anno>MaxHeapSize</anno></c> is an integer, the system default values for <c>kill</c> and <c>error_logger</c> are used. </p> <taglist> <tag><c>size</c></tag> <item> - <p> - The maximum size in words of the process. If set to zero, the - heap size limit is disabled. Badarg will be thrown if the value is - smaller than - <seealso marker="#process_flag_min_heap_size"><c>min_heap_size</c></seealso>. - The size check is only done when a garbage collection is triggered. - </p> - <p> - <c>size</c> is the entire heap of the process when garbage collection - is triggered, this includes all generational heaps, the process stack, + <p>The maximum size in words of the process. If set to zero, the + heap size limit is disabled. <c>badarg</c> is be thrown if the + value is smaller than <seealso marker="#process_flag_min_heap_size"> + <c>min_heap_size</c></seealso>. The size check is only done when + a garbage collection is triggered.</p> + <p><c>size</c> is the entire heap of the process when garbage collection + is triggered. This includes all generational heaps, the process stack, any <seealso marker="#process_flag_message_queue_data"> - messages that are considered to be part of the heap</seealso> and any - extra memory that the garbage collector needs during collection. - </p> - <p> - <c>size</c> is the same as can be retrieved using + messages that are considered to be part of the heap</seealso>, and any + extra memory that the garbage collector needs during collection.</p> + <p><c>size</c> is the same as can be retrieved using <seealso marker="#process_info_total_heap_size"> <c>erlang:process_info(Pid, total_heap_size)</c></seealso>, - or by adding <c>heap_block_size</c>, <c>old_heap_block_size</c> - and <c>mbuf_size</c> from <seealso marker="#process_info_garbage_collection_info"> - <c>erlang:process_info(Pid, garbage_collection_info)</c></seealso>. - </p> + or by adding <c>heap_block_size</c>, <c>old_heap_block_size</c> + and <c>mbuf_size</c> from <seealso marker="#process_info_garbage_collection_info"> + <c>erlang:process_info(Pid, garbage_collection_info)</c></seealso>.</p> </item> <tag><c>kill</c></tag> <item> - <p> - When set to <c>true</c> the runtime system will send an + <p>When set to <c>true</c>, the runtime system sends an untrappable exit signal with reason <c>kill</c> to the process if the maximum heap size is reached. The garbage collection - that triggered the <c>kill</c> will not be completed, instead the - process will exit as soon as is possible. When set to <c>false</c> - no exit signal will be sent to the process, instead it will - continue executing. - </p> - <p> - If <c>kill</c> is not defined in the map + that triggered the <c>kill</c> is not completed, instead the + process exits as soon as possible. When set to <c>false</c>, + no exit signal is sent to the process, instead it continues + executing.</p> + <p>If <c>kill</c> is not defined in the map, the system default will be used. The default system default - is <c>true</c>. It can be changed by either the erl - <seealso marker="erl#+hmaxk">+hmaxk</seealso> option, - or <seealso marker="#system_flag_max_heap_size"><c> - erlang:system_flag(max_heap_size, MaxHeapSize)</c></seealso>. - </p> + is <c>true</c>. It can be changed by either option + <seealso marker="erl#+hmaxk">+hmaxk</seealso> in <c>erl(1)</c>, + or <seealso marker="#system_flag_max_heap_size"> + <c>erlang:system_flag(max_heap_size, MaxHeapSize)</c></seealso>.</p> </item> <tag><c>error_logger</c></tag> <item> - <p> - When set to <c>true</c> the runtime system will send a - message to the current <seealso marker="kernel:error_logger"><c>error_logger</c></seealso> + <p>When set to <c>true</c>, the runtime system sends a + message to the current <seealso marker="kernel:error_logger"> + <c>error_logger</c></seealso> containing details about the process when the maximum - heap size is reached. One <c>error_logger</c> report will - be sent each time the limit is reached. - </p> - <p> - If <c>error_logger</c> is not defined in the map the system - default will be used. The default system default is <c>true</c>. - It can be changed by either the erl <seealso marker="erl#+hmaxel">+hmaxel</seealso> - option, or <seealso marker="#system_flag_max_heap_size"><c> - erlang:system_flag(max_heap_size, MaxHeapSize)</c></seealso>. - </p> + heap size is reached. One <c>error_logger</c> report is sent + each time the limit is reached.</p> + <p>If <c>error_logger</c> is not defined in the map, the system + default is used. The default system default is <c>true</c>. + It can be changed by either the option + <seealso marker="erl#+hmaxel">+hmaxel</seealso> int <c>erl(1)</c>, + or <seealso marker="#system_flag_max_heap_size"> + <c>erlang:system_flag(max_heap_size, MaxHeapSize)</c></seealso>.</p> </item> </taglist> - <p> - The heap size of a process is quite hard to predict, especially the + <p>The heap size of a process is quite hard to predict, especially the amount of memory that is used during the garbage collection. When contemplating using this option, it is recommended to first run it in production with <c>kill</c> set to <c>false</c> and inspect @@ -4444,60 +4525,57 @@ os_prompt% </pre> </p> </desc> </func> + <marker id="process_flag_message_queue_data"/> <func> <name name="process_flag" arity="2" clause_i="6"/> - <fsummary>Set process flag <c>message_queue_data</c> for the calling process</fsummary> + <fsummary>Set process flag message_queue_data for the calling process. + </fsummary> <type name="message_queue_data"/> <desc> - <p>This flag determines how messages in the message queue - are stored. When the flag is:</p> + <p>This flag determines how messages in the message queue + are stored, as follows:</p> <taglist> <tag><c>off_heap</c></tag> - <item><p> - <em>All</em> messages in the message queue will be stored - outside of the process heap. This implies that <em>no</em> - messages in the message queue will be part of a garbage - collection of the process. - </p></item> + <item> + <p><em>All</em> messages in the message queue will be stored + outside of the process heap. This implies that <em>no</em> + messages in the message queue will be part of a garbage + collection of the process.</p> + </item> <tag><c>on_heap</c></tag> - <item><p> - All messages in the message queue will eventually be - placed on heap. They may however temporarily be stored - off heap. This is how messages always have been stored - up until ERTS version 8.0. - </p></item> + <item> + <p>All messages in the message queue will eventually be + placed on heap. They can however temporarily be stored + off heap. This is how messages always have been stored + up until <c>ERTS</c> 8.0.</p> + </item> </taglist> - <p> - The default <c>message_queue_data</c> process flag is determined - by the <seealso marker="erl#+hmqd"><c>+hmqd</c></seealso> - <c>erl</c> command line argument. - </p> - <p> - If the process potentially may get a hugh amount of messages, - you are recommended to set the flag to <c>off_heap</c>. This - since a garbage collection with lots of messages placed on - the heap may become extremly expensive and the process may - consume large amounts of memory. Performance of the - actual message passing is however generally better when not - using the <c>off_heap</c> flag. - </p> - <p> - When changing this flag messages will be moved. This work - has been initiated but not completed when this function - call returns. - </p> + <p>The default <c>message_queue_data</c> process flag is determined + by command-line argument <seealso marker="erl#+hmqd"> + <c>+hmqd</c></seealso> in <c>erl(1)</c>.</p> + <p>If the process potentially can get many messages, + you are advised to set the flag to <c>off_heap</c>. This + because a garbage collection with many messages placed on + the heap can become extremly expensive and the process can + consume large amounts of memory. Performance of the + actual message passing is however generally better when not + using flag <c>off_heap</c>.</p> + <p>When changing this flag messages will be moved. This work + has been initiated but not completed when this function + call returns.</p> <p>Returns the old value of the flag.</p> </desc> </func> + <func> <name name="process_flag" arity="2" clause_i="7"/> - <fsummary>Sets process flag <c>priority</c> for the calling process.</fsummary> + <fsummary>Set process flag priority for the calling process.</fsummary> <type name="priority_level"/> <desc> <p><marker id="process_flag_priority"></marker> Sets the process priority. <c><anno>Level</anno></c> is an atom. - There are four priority levels: <c>low</c>, + Four priority levels exist: <c>low</c>, <c>normal</c>, <c>high</c>, and <c>max</c>. Default is <c>normal</c>.</p> <note> @@ -4511,23 +4589,23 @@ os_prompt% </pre> <c>low</c> are interleaved. Processes on priority <c>low</c> are selected for execution less frequently than processes on priority <c>normal</c>.</p> - <p>When there are runnable processes on priority <c>high</c>, + <p>When runnable processes on priority <c>high</c> exist, no processes on priority <c>low</c> or <c>normal</c> are - selected for execution. Notice however, that this does + selected for execution. Notice however that this does <em>not</em> mean that no processes on priority <c>low</c> - or <c>normal</c> can run when there are processes - running on priority <c>high</c>. On the runtime + or <c>normal</c> can run when processes + are running on priority <c>high</c>. On the runtime system with SMP support, more processes can be running - in parallel than processes on priority <c>high</c>, that is, + in parallel than processes on priority <c>high</c>. That is, a <c>low</c> and a <c>high</c> priority process can execute at the same time.</p> - <p>When there are runnable processes on priority <c>max</c>, + <p>When runnable processes on priority <c>max</c> exist, no processes on priority <c>low</c>, <c>normal</c>, or <c>high</c> are selected for execution. As with priority <c>high</c>, processes on lower priorities can execute in parallel with processes on priority <c>max</c>.</p> - <p>Scheduling is preemptive. Regardless of priority, a process - is preempted when it has consumed more than a certain number + <p>Scheduling is pre-emptive. Regardless of priority, a process + is pre-empted when it has consumed more than a certain number of reductions since the last time it was selected for execution.</p> <note> @@ -4543,7 +4621,7 @@ os_prompt% </pre> take this into account and handle such scenarios by yourself.</p> <p>Making calls from a <c>high</c> priority process into code - that you have no control over can cause the <c>high</c> + that you has no control over can cause the <c>high</c> priority process to wait for a process with lower priority. That is, effectively decreasing the priority of the <c>high</c> priority process during the call. Even if this @@ -4557,8 +4635,8 @@ os_prompt% </pre> <em>especially</em> priority <c>high</c>. A process on priority <c>high</c> is only to perform work for short periods. Busy looping for - long periods in a <c>high</c> priority process does - most likely cause problems, as important OTP servers + long periods in a <c>high</c> priority process causes + most likely problems, as important OTP servers run on priority <c>normal</c>.</p> <p>Returns the old value of the flag.</p> </desc> @@ -4566,10 +4644,10 @@ os_prompt% </pre> <func> <name name="process_flag" arity="2" clause_i="8"/> - <fsummary>Sets process flag <c>save_calls</c> for the calling process.</fsummary> + <fsummary>Set process flag save_calls for the calling process.</fsummary> <desc> <p><c><anno>N</anno></c> must be an integer in the interval 0..10000. - If <c><anno>N</anno></c> is greater than 0, call saving is made + If <c><anno>N</anno></c> > 0, call saving is made active for the process. This means that information about the <c><anno>N</anno></c> most recent global function calls, BIF calls, sends, and @@ -4580,12 +4658,12 @@ os_prompt% </pre> explicitly mentioned. Only a fixed amount of information is saved, as follows:</p> <list type="bulleted"> - <item>A tuple <c>{Module, Function, Arity}</c> for - function calls</item> - <item> The atoms <c>send</c>, <c>'receive'</c>, and + <item><p>A tuple <c>{Module, Function, Arity}</c> for + function calls</p></item> + <item><p>The atoms <c>send</c>, <c>'receive'</c>, and <c>timeout</c> for sends and receives (<c>'receive'</c> when a message is received and <c>timeout</c> when a - receive times out)</item> + receive times out)</p></item> </list> <p>If <c>N</c> = 0, call saving is disabled for the process, which is the @@ -4597,7 +4675,7 @@ os_prompt% </pre> <func> <name name="process_flag" arity="2" clause_i="9"/> - <fsummary>Sets process flag <c>sensitive</c> for the calling process.</fsummary> + <fsummary>Set process flag sensitive for the calling process.</fsummary> <desc> <p>Sets or clears flag <c>sensitive</c> for the current process. When a process has been marked as sensitive by calling @@ -4607,13 +4685,13 @@ os_prompt% </pre> <p>Features that are disabled include (but are not limited to) the following:</p> <list type="bulleted"> - <item>Tracing: Trace flags can still be set for the process, + <item><p>Tracing. Trace flags can still be set for the process, but no trace messages of any kind are generated. (If flag <c>sensitive</c> is turned off, trace messages are again - generated if any trace flags are set.)</item> - <item>Sequential tracing: The sequential trace token is + generated if any trace flags are set.)</p></item> + <item><p>Sequential tracing. The sequential trace token is propagated as usual, but no sequential trace messages are - generated.</item> + generated.</p></item> </list> <p><c>process_info/1,2</c> cannot be used to read out the message queue or the process dictionary (both are returned @@ -4623,19 +4701,19 @@ os_prompt% </pre> are omitted.</p> <p>If <c>{save_calls,N}</c> has been set for the process, no function calls are saved to the call saving list. - (The call saving list is not cleared. Furthermore, send, receive, - and timeout events are still added to the list.)</p> + (The call saving list is not cleared. Also, send, receive, + and time-out events are still added to the list.)</p> <p>Returns the old value of the flag.</p> </desc> </func> <func> <name name="process_flag" arity="3"/> - <fsummary>Sets process flags for a process.</fsummary> + <fsummary>Set process flags for a process.</fsummary> <desc> <p>Sets certain flags for the process <c><anno>Pid</anno></c>, in the same manner as - <seealso marker="#process_flag/2">process_flag/2</seealso>. + <seealso marker="#process_flag/2"><c>process_flag/2</c></seealso>. Returns the old value of the flag. The valid values for <c><anno>Flag</anno></c> are only a subset of those allowed in <c>process_flag/2</c>, namely <c>save_calls</c>.</p> @@ -4650,46 +4728,46 @@ os_prompt% </pre> <type name="process_info_result_item"/> <type name="priority_level"/> <type name="stack_item"/> - <type name="max_heap_size" /> - <type name="message_queue_data" /> + <type name="max_heap_size"/> + <type name="message_queue_data"/> <desc> <p>Returns a list containing <c><anno>InfoTuple</anno></c>s with - miscellaneous information about the process identified by - <c>Pid</c>, or <c>undefined</c> if the process is not alive.</p> - <p>The order of the <c><anno>InfoTuple</anno></c>s is undefined and - all <c><anno>InfoTuple</anno></c>s are not mandatory. + miscellaneous information about the process identified by + <c>Pid</c>, or <c>undefined</c> if the process is not alive.</p> + <p>The order of the <c><anno>InfoTuple</anno></c>s is undefined and + all <c><anno>InfoTuple</anno></c>s are not mandatory. The <c><anno>InfoTuple</anno></c>s - part of the result can be changed without prior notice.</p> - <p>The <c><anno>InfoTuple</anno></c>s with the following items - are part of the result:</p> + part of the result can be changed without prior notice.</p> + <p>The <c><anno>InfoTuple</anno></c>s with the following items + are part of the result:</p> <list type="bulleted"> <item><c>current_function</c></item> <item><c>initial_call</c></item> <item><c>status</c></item> - <item><c>message_queue_len</c></item> + <item><c>message_queue_len</c></item> <item><c>messages</c></item> <item><c>links</c></item> - <item><c>dictionary</c></item> + <item><c>dictionary</c></item> <item><c>trap_exit</c></item> <item><c>error_handler</c></item> - <item><c>priority</c></item> + <item><c>priority</c></item> <item><c>group_leader</c></item> <item><c>total_heap_size</c></item> - <item><c>heap_size</c></item> + <item><c>heap_size</c></item> <item><c>stack_size</c></item> <item><c>reductions</c></item> - <item><c>garbage_collection</c></item> + <item><c>garbage_collection</c></item> </list> <p>If the process identified by <c><anno>Pid</anno></c> has a registered name, - also an <c><anno>InfoTuple</anno></c> with item <c>registered_name</c> - appears.</p> - <p>For information about specific <c><anno>InfoTuple</anno></c>s, see - <seealso marker="#process_info/2">process_info/2</seealso>.</p> + also an <c><anno>InfoTuple</anno></c> with item <c>registered_name</c> + is included.</p> + <p>For information about specific <c><anno>InfoTuple</anno></c>s, see + <seealso marker="#process_info/2"><c>process_info/2</c></seealso>.</p> <warning> <p>This BIF is intended for <em>debugging only</em>. For - all other purposes, use - <seealso marker="#process_info/2">process_info/2</seealso>.</p> + all other purposes, use <seealso marker="#process_info/2"> + <c>process_info/2</c></seealso>.</p> </warning> <p>Failure: <c>badarg</c> if <c><anno>Pid</anno></c> is not a local process.</p> @@ -4704,38 +4782,39 @@ os_prompt% </pre> <type name="process_info_result_item"/> <type name="stack_item"/> <type name="priority_level"/> - <type name="max_heap_size" /> - <type name="message_queue_data" /> + <type name="max_heap_size"/> + <type name="message_queue_data"/> <desc> <p>Returns information about the process identified by - <c><anno>Pid</anno></c>, as specified by - <c><anno>Item</anno></c> or <c><anno>ItemList</anno></c>. - Returns <c>undefined</c> if the process is not alive.</p> - <p>If the process is alive and a single <c><anno>Item</anno></c> - is given, the returned value is the corresponding - <c><anno>InfoTuple</anno></c>, unless <c>Item =:= registered_name</c> - and the process has no registered name. In this case, - <c>[]</c> is returned. This strange behavior is because of - historical reasons, and is kept for backward compatibility.</p> - <p>If <c><anno>ItemList</anno></c> is given, the result is - <c><anno>InfoTupleList</anno></c>. - The <c><anno>InfoTuple</anno></c>s in - <c><anno>InfoTupleList</anno></c> appear with the corresponding - <c><anno>Item</anno></c>s in the same order as the - <c><anno>Item</anno></c>s appeared - in <c><anno>ItemList</anno></c>. Valid <c><anno>Item</anno></c>s can - appear multiple times in <c><anno>ItemList</anno></c>.</p> - <note><p>If <c>registered_name</c> is part of <c><anno>ItemList</anno></c> - and the process has no name registered a - <c>{registered_name, []}</c>, <c><anno>InfoTuple</anno></c> - <em>will</em> appear in the resulting - <c><anno>InfoTupleList</anno></c>. This - behavior is different when a single - <c>Item =:= registered_name</c> is given, and when - <c>process_info/1</c> is used.</p> - </note> - <p>The following <c><anno>InfoTuple</anno></c>s with corresponding - <c><anno>Item</anno></c>s are valid:</p> + <c><anno>Pid</anno></c>, as specified by + <c><anno>Item</anno></c> or <c><anno>ItemList</anno></c>. + Returns <c>undefined</c> if the process is not alive.</p> + <p>If the process is alive and a single <c><anno>Item</anno></c> + is specified, the returned value is the corresponding + <c><anno>InfoTuple</anno></c>, unless <c>Item =:= registered_name</c> + and the process has no registered name. In this case, + <c>[]</c> is returned. This strange behavior is because of + historical reasons, and is kept for backward compatibility.</p> + <p>If <c><anno>ItemList</anno></c> is specified, the result is + <c><anno>InfoTupleList</anno></c>. + The <c><anno>InfoTuple</anno></c>s in + <c><anno>InfoTupleList</anno></c> are included with the corresponding + <c><anno>Item</anno></c>s in the same order as the + <c><anno>Item</anno></c>s were included + in <c><anno>ItemList</anno></c>. Valid <c><anno>Item</anno></c>s can + be included multiple times in <c><anno>ItemList</anno></c>.</p> + <note> + <p>If <c>registered_name</c> is part of <c><anno>ItemList</anno></c> + and the process has no name registered, a + <c>{registered_name, []}</c>, <c><anno>InfoTuple</anno></c> + <em>will</em> be included in the resulting + <c><anno>InfoTupleList</anno></c>. This + behavior is different when a single + <c>Item =:= registered_name</c> is specified, and when + <c>process_info/1</c> is used.</p> + </note> + <p>Valid <c><anno>InfoTuple</anno></c>s with corresponding + <c><anno>Item</anno></c>s:</p> <taglist> <tag><c>{backtrace, <anno>Bin</anno>}</c></tag> <item> @@ -4748,15 +4827,15 @@ os_prompt% </pre> <tag><c>{binary, <anno>BinInfo</anno>}</c></tag> <item> <p><c><anno>BinInfo</anno></c> is a list containing miscellaneous - information about binaries currently being referred to by this + information about binaries currently referred to by this process. This <c><anno>InfoTuple</anno></c> can be changed or removed without prior notice.</p> </item> <tag><c>{catchlevel, <anno>CatchLevel</anno>}</c></tag> <item> <p><c><anno>CatchLevel</anno></c> is the number of currently active - catches in this process. This <c><anno>InfoTuple</anno></c> can be - changed or removed without prior notice.</p> + catches in this process. This <c><anno>InfoTuple</anno></c> can be + changed or removed without prior notice.</p> </item> <tag><c>{current_function, {<anno>Module</anno>, <anno>Function</anno>, Arity}}</c></tag> @@ -4772,14 +4851,15 @@ os_prompt% </pre> <p><c><anno>Module</anno></c>, <c><anno>Function</anno></c>, <c><anno>Arity</anno></c> is the current function call of the process. - <c><anno>Location</anno></c> is a list of two-tuples describing the - location in the source code.</p> + <c><anno>Location</anno></c> is a list of two-tuples describing + the location in the source code.</p> </item> <tag><c>{current_stacktrace, <anno>Stack</anno>}</c></tag> <item> <p>Returns the current call stack back-trace (<em>stacktrace</em>) of the process. The stack has the same format as returned by - <seealso marker="#get_stacktrace/0">erlang:get_stacktrace/0</seealso>.</p> + <seealso marker="#get_stacktrace/0"> + <c>erlang:get_stacktrace/0</c></seealso>.</p> </item> <tag><c>{dictionary, <anno>Dictionary</anno>}</c></tag> <item> @@ -4793,9 +4873,9 @@ os_prompt% </pre> <tag><c>{garbage_collection, <anno>GCInfo</anno>}</c></tag> <item> <p><c><anno>GCInfo</anno></c> is a list containing miscellaneous - information about garbage collection for this process. - The content of <c><anno>GCInfo</anno></c> can be changed without - prior notice.</p> + information about garbage collection for this process. + The content of <c><anno>GCInfo</anno></c> can be changed without + prior notice.</p> </item> <tag> <marker id="process_info_garbage_collection_info"/> @@ -4803,24 +4883,22 @@ os_prompt% </pre> </tag> <item> <p><c><anno>GCInfo</anno></c> is a list containing miscellaneous - detailed information about garbage collection for this process. - The content of <c><anno>GCInfo</anno></c> can be changed without - prior notice. - See <seealso marker="#gc_minor_start">gc_minor_start</seealso> in - <seealso marker="#trace/3">erlang:trace/3</seealso> for details about - what each item means. - </p> + detailed information about garbage collection for this process. + The content of <c><anno>GCInfo</anno></c> can be changed without + prior notice. For details about the meaning of each item, see + <seealso marker="#gc_minor_start"><c>gc_minor_start</c></seealso> + in <seealso marker="#trace/3"><c>erlang:trace/3</c></seealso>.</p> </item> <tag><c>{group_leader, <anno>GroupLeader</anno>}</c></tag> <item> - <p><c><anno>GroupLeader</anno></c> is group leader for the I/O of - the process.</p> + <p><c><anno>GroupLeader</anno></c> is the group leader for the I/O + of the process.</p> </item> <tag><c>{heap_size, <anno>Size</anno>}</c></tag> <item> - <p><c><anno>Size</anno></c> is the size in words of the youngest heap - generation of the process. This generation includes - the process stack. This information is highly + <p><c><anno>Size</anno></c> is the size in words of the youngest + heap generation of the process. This generation includes + the process stack. This information is highly implementation-dependent, and can change if the implementation changes.</p> </item> @@ -4834,29 +4912,29 @@ os_prompt% </pre> </item> <tag><c>{links, <anno>PidsAndPorts</anno>}</c></tag> <item> - <p><c><anno>PidsAndPorts</anno></c> is a list of process identifiers - and port identifiers, with processes or ports to which the process - has a link.</p> + <p><c><anno>PidsAndPorts</anno></c> is a list of process identifiers + and port identifiers, with processes or ports to which the process + has a link.</p> </item> <tag><c>{last_calls, false|Calls}</c></tag> <item> <p>The value is <c>false</c> if call saving is not active - for the process (see - <seealso marker="#process_flag/3">process_flag/3</seealso>). + for the process (see <seealso marker="#process_flag/3"> + <c>process_flag/3</c></seealso>). If call saving is active, a list is returned, in which the last element is the most recent called.</p> </item> <tag><c>{memory, <anno>Size</anno>}</c></tag> <item> - <p><c><anno>Size</anno></c> is the size in bytes of the process. This - includes call stack, heap, and internal structures.</p> + <p><c><anno>Size</anno></c> is the size in bytes of the process. + This includes call stack, heap, and internal structures.</p> </item> <tag><c>{message_queue_len, <anno>MessageQueueLen</anno>}</c></tag> <item> <p><c><anno>MessageQueueLen</anno></c> is the number of messages - currently in the message queue of the process. This is - the length of the list <c><anno>MessageQueue</anno></c> returned as - the information item <c>messages</c> (see the following).</p> + currently in the message queue of the process. This is the + length of the list <c><anno>MessageQueue</anno></c> returned as + the information item <c>messages</c> (see below).</p> </item> <tag><c>{messages, <anno>MessageQueue</anno>}</c></tag> <item> @@ -4899,36 +4977,37 @@ os_prompt% </pre> </item> <tag><c>{message_queue_data, <anno>MQD</anno>}</c></tag> <item> - <p>Returns the current state of the <c>message_queue_data</c> - process flag. <c><anno>MQD</anno></c> is either <c>off_heap</c>, - or <c>on_heap</c>. For more information, see the - documentation of - <seealso marker="#process_flag_message_queue_data"><c>process_flag(message_queue_data, - MQD)</c></seealso>.</p> + <p>Returns the current state of process flag + <c>message_queue_data</c>. <c><anno>MQD</anno></c> is either + <c>off_heap</c> or <c>on_heap</c>. For more + information, see the documentation of + <seealso marker="#process_flag_message_queue_data"> + <c>process_flag(message_queue_data, MQD)</c></seealso>.</p> </item> <tag><c>{priority, <anno>Level</anno>}</c></tag> <item> <p><c><anno>Level</anno></c> is the current priority level for - the process. For more information on priorities, see - <seealso marker="#process_flag_priority">process_flag(priority, - Level)</seealso>.</p> + the process. For more information on priorities, see + <seealso marker="#process_flag_priority"> + <c>process_flag(priority, Level)</c></seealso>.</p> </item> <tag><c>{reductions, <anno>Number</anno>}</c></tag> <item> - <p><c><anno>Number</anno></c> is the number of reductions executed by - the process.</p> + <p><c><anno>Number</anno></c> is the number of reductions executed + by the process.</p> </item> <tag><c>{registered_name, <anno>Atom</anno>}</c></tag> <item> - <p><c><anno>Atom</anno></c> is the registered name of the process. If - the process has no registered name, this tuple is not + <p><c><anno>Atom</anno></c> is the registered process name. + If the process has no registered name, this tuple is not present in the list.</p> </item> - <tag><c>{sequential_trace_token, [] | <anno>SequentialTraceToken</anno>}</c></tag> + <tag><c>{sequential_trace_token, [] | + <anno>SequentialTraceToken</anno>}</c></tag> <item> <p><c><anno>SequentialTraceToken</anno></c> is the sequential trace - token for the process. This <c><anno>InfoTuple</anno></c> can be - changed or removed without prior notice.</p> + token for the process. This <c><anno>InfoTuple</anno></c> can be + changed or removed without prior notice.</p> </item> <tag><c>{stack_size, <anno>Size</anno>}</c></tag> <item> @@ -4937,9 +5016,9 @@ os_prompt% </pre> </item> <tag><c>{status, <anno>Status</anno>}</c></tag> <item> - <p><c><anno>Status</anno></c> is the status of the process and is one - of the following:</p> - <list type="bulleted"> + <p><c><anno>Status</anno></c> is the status of the process and is + one of the following:</p> + <list type="bulleted"> <item><c>exiting</c></item> <item><c>garbage_collecting</c></item> <item><c>waiting</c> (for a message)</item> @@ -4947,46 +5026,44 @@ os_prompt% </pre> <item><c>runnable</c> (ready to run, but another process is running)</item> <item><c>suspended</c> (suspended on a "busy" port - or by the BIF <c>erlang:suspend_process/[1,2]</c>)</item> + or by the BIF <c>erlang:suspend_process/1,2</c>)</item> </list> </item> <tag><c>{suspending, <anno>SuspendeeList</anno>}</c></tag> <item> <p><c><anno>SuspendeeList</anno></c> is a list of - <c>{<anno>Suspendee</anno>, <anno>ActiveSuspendCount</anno>, - <anno>OutstandingSuspendCount</anno>}</c> tuples. - <c><anno>Suspendee</anno></c> is the process identifier of a - process that has been, or is to be, - suspended by the process identified by <c><anno>Pid</anno></c> - through one of the following BIFs:</p> + <c>{<anno>Suspendee</anno>, <anno>ActiveSuspendCount</anno>, + <anno>OutstandingSuspendCount</anno>}</c> tuples. + <c><anno>Suspendee</anno></c> is the process identifier of a + process that has been, or is to be, + suspended by the process identified by <c><anno>Pid</anno></c> + through the BIF <seealso marker="#suspend_process/2"> + <c>erlang:suspend_process/2</c></seealso> or + <seealso marker="#suspend_process/1"> + <c>erlang:suspend_process/1</c></seealso>.</p> + <p><c><anno>ActiveSuspendCount</anno></c> is the number of + times <c><anno>Suspendee</anno></c> has been suspended by + <c><anno>Pid</anno></c>. + <c><anno>OutstandingSuspendCount</anno></c> is the number of not + yet completed suspend requests sent by <c><anno>Pid</anno></c>, + that is:</p> <list type="bulleted"> <item> - <seealso marker="#suspend_process/2">erlang:suspend_process/2</seealso> - </item> - <item> - <seealso marker="#suspend_process/1">erlang:suspend_process/1</seealso> - </item> - </list> - <p><c><anno>ActiveSuspendCount</anno></c> is the number of - times <c><anno>Suspendee</anno></c> has been suspended by - <c><anno>Pid</anno></c>. - <c><anno>OutstandingSuspendCount</anno></c> is the number of not yet - completed suspend requests sent by <c><anno>Pid</anno></c>, that is:</p> - <list type="bulleted"> - <item>If <c><anno>ActiveSuspendCount</anno> =/= 0</c>, - <c><anno>Suspendee</anno></c> is - currently in the suspended state. + <p>If <c><anno>ActiveSuspendCount</anno> =/= 0</c>, + <c><anno>Suspendee</anno></c> is + currently in the suspended state.</p> </item> - <item>If <c><anno>OutstandingSuspendCount</anno> =/= 0</c>, option - <c>asynchronous</c> of <c>erlang:suspend_process/2</c> - has been used and the suspendee has not yet been - suspended by <c><anno>Pid</anno></c>. + <item> + <p>If <c><anno>OutstandingSuspendCount</anno> =/= 0</c>, + option <c>asynchronous</c> of <c>erlang:suspend_process/2</c> + has been used and the suspendee has not yet been + suspended by <c><anno>Pid</anno></c>.</p> </item> </list> - <p>Notice that <c><anno>ActiveSuspendCount</anno></c> and - <c><anno>OutstandingSuspendCount</anno></c> are not the - total suspend count on <c><anno>Suspendee</anno></c>, - only the parts contributed by <c><anno>Pid</anno></c>.</p> + <p>Notice that <c><anno>ActiveSuspendCount</anno></c> and + <c><anno>OutstandingSuspendCount</anno></c> are not the + total suspend count on <c><anno>Suspendee</anno></c>, + only the parts contributed by <c><anno>Pid</anno></c>.</p> </item> <tag> <marker id="process_info_total_heap_size"/> @@ -4994,21 +5071,21 @@ os_prompt% </pre> </tag> <item> <p><c><anno>Size</anno></c> is the total size, in words, of all heap - fragments of the process. This includes the process stack and - any unreceived messages that are considered to be part of the - heap. </p> + fragments of the process. This includes the process stack and + any unreceived messages that are considered to be part of the + heap.</p> </item> <tag><c>{trace, <anno>InternalTraceFlags</anno>}</c></tag> <item> <p><c><anno>InternalTraceFlags</anno></c> is an integer - representing the internal trace flag for this process. - This <c><anno>InfoTuple</anno></c> - can be changed or removed without prior notice.</p> + representing the internal trace flag for this process. + This <c><anno>InfoTuple</anno></c> + can be changed or removed without prior notice.</p> </item> <tag><c>{trap_exit, <anno>Boolean</anno>}</c></tag> <item> <p><c><anno>Boolean</anno></c> is <c>true</c> if the process - is trapping exits, otherwise <c>false</c>.</p> + is trapping exits, otherwise <c>false</c>.</p> </item> </taglist> <p>Notice that not all implementations support all @@ -5016,9 +5093,9 @@ os_prompt% </pre> <p>Failures:</p> <taglist> <tag><c>badarg</c></tag> - <item>If <c><anno>Pid</anno></c> is not a local process.</item> + <item>If <c><anno>Pid</anno></c> is not a local process.</item> <tag><c>badarg</c></tag> - <item>If <c><anno>Item</anno></c> is an invalid item.</item> + <item>If <c><anno>Item</anno></c> is an invalid item.</item> </taglist> </desc> </func> @@ -5028,11 +5105,11 @@ os_prompt% </pre> <fsummary>All processes.</fsummary> <desc> <p>Returns a list of process identifiers corresponding to - all the processes currently existing on the local node.</p> - <p>Notice that an exiting process exists, but is not alive. - That is, <c>is_process_alive/1</c> returns <c>false</c> - for an exiting process, but its process identifier is part - of the result returned from <c>processes/0</c>.</p> + all the processes currently existing on the local node.</p> + <p>Notice that an exiting process exists, but is not alive. + That is, <c>is_process_alive/1</c> returns <c>false</c> + for an exiting process, but its process identifier is part + of the result returned from <c>processes/0</c>.</p> <p>Example:</p> <pre> > <input>processes().</input> @@ -5042,22 +5119,23 @@ os_prompt% </pre> <func> <name name="purge_module" arity="1"/> - <fsummary>Removes old code for a module.</fsummary> + <fsummary>Remove old code for a module.</fsummary> <desc> <p>Removes old code for <c><anno>Module</anno></c>. Before this BIF is used, - <c>erlang:check_process_code/2</c> is to be called to check + <seealso marker="#check_process_code/2"> + <c>check_process_code/2</c></seealso>is to be called to check that no processes execute old code in the module.</p> <warning> <p>This BIF is intended for the code server (see - <seealso marker="kernel:code">code(3)</seealso>) + <seealso marker="kernel:code"><c>kernel:code(3)</c></seealso>) and is not to be used elsewhere.</p> </warning> <note> - <p>As from <c>ERTS</c> 8.0 (OTP 19), any lingering processes - that still execute the old code will be killed by this function. - In earlier versions, such incorrect use could cause much - more fatal failures, like emulator crash.</p> + <p>As from <c>ERTS</c> 8.0 (Erlang/OTP 19), any lingering processes + that still execute the old code is killed by this function. + In earlier versions, such incorrect use could cause much + more fatal failures, like emulator crash.</p> </note> <p>Failure: <c>badarg</c> if there is no old code for <c><anno>Module</anno></c>.</p> @@ -5066,14 +5144,13 @@ os_prompt% </pre> <func> <name name="put" arity="2"/> - <fsummary>Adds a new value to the process dictionary.</fsummary> + <fsummary>Add a new value to the process dictionary.</fsummary> <desc> <p>Adds a new <c><anno>Key</anno></c> to the process dictionary, associated with the value <c><anno>Val</anno></c>, and returns <c>undefined</c>. If <c><anno>Key</anno></c> exists, the old value is deleted and replaced by <c><anno>Val</anno></c>, and - the function returns the old value.</p> - <p>Example:</p> + the function returns the old value. Example:</p> <pre> > <input>X = put(name, walrus), Y = put(name, carpenter),</input> <input>Z = get(name),</input> @@ -5089,17 +5166,18 @@ os_prompt% </pre> <func> <name name="raise" arity="3"/> - <fsummary>Stops execution with an exception of given class, reason, and call stack backtrace.</fsummary> + <fsummary>Stop execution with an exception of specified class, reason, + and call stack backtrace.</fsummary> <type name="raise_stacktrace"/> <desc> <p>Stops the execution of the calling process with an - exception of given class, reason, and call stack backtrace + exception of the specified class, reason, and call stack backtrace (<em>stacktrace</em>).</p> <p><c><anno>Class</anno></c> is <c>error</c>, <c>exit</c>, or <c>throw</c>. So, if it were not for the stacktrace, <c>erlang:raise(<anno>Class</anno>, <anno>Reason</anno>, - <anno>Stacktrace</anno>)</c> is - equivalent to <c>erlang:<anno>Class</anno>(<anno>Reason</anno>)</c>.</p> + <anno>Stacktrace</anno>)</c> is equivalent to + <c>erlang:<anno>Class</anno>(<anno>Reason</anno>)</c>.</p> <p><c><anno>Reason</anno></c> is any term. <c><anno>Stacktrace</anno></c> is a list as returned from <c>get_stacktrace()</c>, that is, a list of @@ -5109,12 +5187,12 @@ os_prompt% </pre> argument list. The stacktrace can also contain <c>{Fun, Args, Location}</c> tuples, where <c>Fun</c> is a local fun and <c>Args</c> is an argument list.</p> - <p>Element <c>Location</c> at the end is optional. - Omitting it is equivalent to specifying an empty list.</p> + <p>Element <c>Location</c> at the end is optional. + Omitting it is equivalent to specifying an empty list.</p> <p>The stacktrace is used as the exception stacktrace for the calling process; it is truncated to the current maximum stacktrace depth.</p> - <p>Since evaluating this function causes the process to + <p>As evaluating this function causes the process to terminate, it has no return value unless the arguments are invalid, in which case the function <em>returns the error reason</em> <c>badarg</c>. If you want to be @@ -5126,78 +5204,68 @@ os_prompt% </pre> </func> <func> - <name name="read_timer" arity="2"/> - <fsummary>Reads the state of a timer.</fsummary> + <name name="read_timer" arity="1"/> + <fsummary>Read the state of a timer.</fsummary> <desc> - <p> - Read the state of a timer that has been created by either - <seealso marker="#start_timer/4"><c>erlang:start_timer()</c></seealso>, - or <seealso marker="#send_after/4"><c>erlang:send_after()</c></seealso>. - <c><anno>TimerRef</anno></c> identifies the timer, and - was returned by the BIF that created the timer. - </p> - <p>Available <c><anno>Option</anno>s</c>:</p> + <p>Reads the state of a timer. The same as calling + <seealso marker="#read_timer/2"><c>erlang:read_timer(TimerRef, + [])</c></seealso>.</p> + </desc> + </func> + + <func> + <name name="read_timer" arity="2"/> + <fsummary>Read the state of a timer.</fsummary> + <desc> + <p>Reads the state of a timer that has been created by either + <seealso marker="#start_timer/4"><c>erlang:start_timer</c></seealso> + or <seealso marker="#send_after/4"><c>erlang:send_after</c></seealso>. + <c><anno>TimerRef</anno></c> identifies the timer, and + was returned by the BIF that created the timer.</p> + <p><c><anno>Option</anno>s</c>:</p> <taglist> - <tag><c>{async, Async}</c></tag> - <item> - <p> - Asynchronous request for state information. <c>Async</c> - defaults to <c>false</c> which will cause the operation - to be performed synchronously. In this case, the <c>Result</c> - is returned by <c>erlang:read_timer()</c>. When - <c>Async</c> is <c>true</c>, <c>erlang:read_timer()</c> - sends an asynchronous request for the state information - to the timer service that manages the timer, and then returns - <c>ok</c>. A message on the format <c>{read_timer, - <anno>TimerRef</anno>, <anno>Result</anno>}</c> is - sent to the caller of <c>erlang:read_timer()</c> when the - operation has been processed. - </p> - </item> + <tag><c>{async, Async}</c></tag> + <item> + <p>Asynchronous request for state information. <c>Async</c> + defaults to <c>false</c>, which causes the operation + to be performed synchronously. In this case, the <c>Result</c> + is returned by <c>erlang:read_timer</c>. When + <c>Async</c> is <c>true</c>, <c>erlang:read_timer</c> + sends an asynchronous request for the state information + to the timer service that manages the timer, and then returns + <c>ok</c>. A message on the format <c>{read_timer, + <anno>TimerRef</anno>, <anno>Result</anno>}</c> is + sent to the caller of <c>erlang:read_timer</c> when the + operation has been processed.</p> + </item> </taglist> - <p> - More <c><anno>Option</anno></c>s may be added in the future. - </p> - <p> - If <c><anno>Result</anno></c> is an integer, it represents the - time in milli-seconds left until the timer expires.</p> - <p> - If <c><anno>Result</anno></c> is <c>false</c>, a - timer corresponding to <c><anno>TimerRef</anno></c> could not - be found. This can be because the timer had expired, - it had been canceled, or because <c><anno>TimerRef</anno></c> - never has corresponded to a timer. Even if the timer has expired, - it does not tell you whether or not the timeout message has - arrived at its destination yet. - </p> - <note> - <p> - The timer service that manages the timer may be co-located - with another scheduler than the scheduler that the calling - process is executing on. If this is the case, communication - with the timer service takes much longer time than if it - is located locally. If the calling process is in critical - path, and can do other things while waiting for the result - of this operation, you want to use option <c>{async, true}</c>. - If using option <c>{async, false}</c>, the calling - process will be blocked until the operation has been - performed. - </p> - </note> + <p>More <c><anno>Option</anno></c>s can be added in the future.</p> + <p>If <c><anno>Result</anno></c> is an integer, it represents the + time in milliseconds left until the timer expires.</p> + <p>If <c><anno>Result</anno></c> is <c>false</c>, a + timer corresponding to <c><anno>TimerRef</anno></c> could not + be found. This because the timer had expired, + or been canceled, or because <c><anno>TimerRef</anno></c> + never has corresponded to a timer. Even if the timer has expired, + it does not tell you whether or not the time-out message has + arrived at its destination yet.</p> + <note> + <p>The timer service that manages the timer can be co-located + with another scheduler than the scheduler that the calling + process is executing on. If so, communication + with the timer service takes much longer time than if it + is located locally. If the calling process is in a critical + path, and can do other things while waiting for the result + of this operation, you want to use option <c>{async, true}</c>. + If using option <c>{async, false}</c>, the calling + process is blocked until the operation has been performed.</p> + </note> <p>See also <seealso marker="#send_after/4"><c>erlang:send_after/4</c></seealso>, - <seealso marker="#start_timer/4"><c>erlang:start_timer/4</c></seealso>, - and - <seealso marker="#cancel_timer/2"><c>erlang:cancel_timer/2</c></seealso>.</p> - </desc> - </func> - <func> - <name name="read_timer" arity="1"/> - <fsummary>Reads the state of a timer.</fsummary> - <desc> - <p>Read the state of a timer. The same as calling - <seealso marker="#read_timer/2"><c>erlang:read_timer(TimerRef, - [])</c></seealso>.</p> + <seealso marker="#start_timer/4"> + <c>erlang:start_timer/4</c></seealso>, and + <seealso marker="#cancel_timer/2"> + <c>erlang:cancel_timer/2</c></seealso>.</p> </desc> </func> @@ -5209,21 +5277,20 @@ os_prompt% </pre> representation of <c><anno>Ref</anno></c>.</p> <warning> <p>This BIF is intended for debugging and is not to be used - in application programs.</p> + in application programs.</p> </warning> </desc> </func> <func> <name name="register" arity="2"/> - <fsummary>Registers a name for a pid (or port).</fsummary> + <fsummary>Register a name for a pid (or port).</fsummary> <desc> <p>Associates the name <c><anno>RegName</anno></c> with a process identifier (pid) or a port identifier. <c><anno>RegName</anno></c>, which must be an atom, can be used instead of the pid or port identifier in send operator - (<c><anno>RegName</anno> ! Message</c>).</p> - <p>Example:</p> + (<c><anno>RegName</anno> ! Message</c>). Example:</p> <pre> > <input>register(db, Pid).</input> true</pre> @@ -5249,7 +5316,7 @@ true</pre> <fsummary>All registered names.</fsummary> <desc> <p>Returns a list of names that have been registered using - <seealso marker="#register/2">register/2</seealso>, for + <seealso marker="#register/2"><c>register/2</c></seealso>, for example:</p> <pre> > <input>registered().</input> @@ -5259,20 +5326,21 @@ true</pre> <func> <name name="resume_process" arity="1"/> - <fsummary>Resumes a suspended process.</fsummary> + <fsummary>Resume a suspended process.</fsummary> <desc> <p>Decreases the suspend count on the process identified by - <c><anno>Suspendee</anno></c>. <c><anno>Suspendee</anno></c> - is previously to have been suspended through - <seealso marker="#suspend_process/2">erlang:suspend_process/2</seealso> - or - <seealso marker="#suspend_process/1">erlang:suspend_process/1</seealso> - by the process calling - <c>erlang:resume_process(<anno>Suspendee</anno>)</c>. When the - suspend count on <c><anno>Suspendee</anno></c> reaches zero, - <c><anno>Suspendee</anno></c> is resumed, that is, its state - is changed from suspended into the state it had before it was - suspended.</p> + <c><anno>Suspendee</anno></c>. <c><anno>Suspendee</anno></c> + is previously to have been suspended through + <seealso marker="#suspend_process/2"> + <c>erlang:suspend_process/2</c></seealso> or + <seealso marker="#suspend_process/1"> + <c>erlang:suspend_process/1</c></seealso> + by the process calling + <c>erlang:resume_process(<anno>Suspendee</anno>)</c>. When the + suspend count on <c><anno>Suspendee</anno></c> reaches zero, + <c><anno>Suspendee</anno></c> is resumed, that is, its state + is changed from suspended into the state it had before it was + suspended.</p> <warning> <p>This BIF is intended for debugging only.</p> </warning> @@ -5280,29 +5348,29 @@ true</pre> <taglist> <tag><c>badarg</c></tag> <item> - If <c><anno>Suspendee</anno></c> is not a process identifier. - </item> + If <c><anno>Suspendee</anno></c> is not a process identifier. + </item> <tag><c>badarg</c></tag> <item> - If the process calling <c>erlang:resume_process/1</c> had - not previously increased the suspend count on the process - identified by <c><anno>Suspendee</anno></c>. - </item> + If the process calling <c>erlang:resume_process/1</c> had + not previously increased the suspend count on the process + identified by <c><anno>Suspendee</anno></c>. + </item> <tag><c>badarg</c></tag> <item> - If the process identified by <c><anno>Suspendee</anno></c> - is not alive. - </item> + If the process identified by <c><anno>Suspendee</anno></c> + is not alive. + </item> </taglist> </desc> </func> <func> <name name="round" arity="1"/> - <fsummary>Returns an integer by rounding a number.</fsummary> + <fsummary>Return an integer by rounding a number.</fsummary> <desc> <p>Returns an integer by rounding <c><anno>Number</anno></c>, - for example:</p> + for example:</p> <pre> <input>round(5.5).</input> 6</pre> @@ -5312,7 +5380,7 @@ true</pre> <func> <name name="self" arity="0"/> - <fsummary>Returns pid of the calling process.</fsummary> + <fsummary>Return pid of the calling process.</fsummary> <desc> <p>Returns the process identifier of the calling process, for example:</p> @@ -5325,7 +5393,7 @@ true</pre> <func> <name name="send" arity="2"/> - <fsummary>Sends a message.</fsummary> + <fsummary>Send a message.</fsummary> <type name="dst"/> <desc> <p>Sends a message and returns <c><anno>Msg</anno></c>. This @@ -5339,27 +5407,27 @@ true</pre> <func> <name name="send" arity="3"/> - <fsummary>Sends a message conditionally.</fsummary> + <fsummary>Send a message conditionally.</fsummary> <type name="dst"/> <desc> <p>Either sends a message and returns <c>ok</c>, or does not send - the message but returns something else (see the following). + the message but returns something else (see below). Otherwise the same as - <seealso marker="#send/2">erlang:send/2</seealso>. + <seealso marker="#send/2"><c>erlang:send/2</c></seealso>. For more detailed explanation and warnings, see - <seealso marker="#send_nosuspend/2">erlang:send_nosuspend/2,3</seealso>.</p> - <p>The options are as follows:</p> + <seealso marker="#send_nosuspend/2"> + <c>erlang:send_nosuspend/2,3</c></seealso>.</p> + <p>Options:</p> <taglist> <tag><c>nosuspend</c></tag> - <item> - <p>If the sender would have to be suspended to do the send, - <c>nosuspend</c> is returned instead.</p> + <item>If the sender would have to be suspended to do the send, + <c>nosuspend</c> is returned instead. </item> <tag><c>noconnect</c></tag> <item> - <p>If the destination node would have to be auto-connected - to do the send, <c>noconnect</c> is returned - instead.</p> + If the destination node would have to be auto-connected + to do the send, <c>noconnect</c> is returned + instead. </item> </taglist> <warning> @@ -5370,36 +5438,37 @@ true</pre> </func> <func> - <name name="send_after" arity="4"/> - <fsummary>Start a timer</fsummary> + <name name="send_after" arity="3"/> + <fsummary>Start a timer.</fsummary> <desc> - <p> - Starts a timer. When the timer expires, the message - <c><anno>Msg</anno></c> is sent to the process - identified by <c><anno>Dest</anno></c>. Apart from - the format of the timeout message, - <c>erlang:send_after/4</c> works exactly as - <seealso marker="#start_timer/4"><c>erlang:start_timer/4</c></seealso>.</p> + <p>Starts a timer. The same as calling + <seealso marker="#send_after/4"> + <c>erlang:send_after(<anno>Time</anno>, <anno>Dest</anno>, + <anno>Msg</anno>, [])</c></seealso>.</p> </desc> </func> + <func> - <name name="send_after" arity="3"/> - <fsummary>Starts a timer.</fsummary> + <name name="send_after" arity="4"/> + <fsummary>Start a timer.</fsummary> <desc> - <p>Starts a timer. The same as calling - <seealso marker="#send_after/4"><c>erlang:send_after(<anno>Time</anno>, - <anno>Dest</anno>, <anno>Msg</anno>, [])</c></seealso>.</p> + <p>Starts a timer. When the timer expires, the message + <c><anno>Msg</anno></c> is sent to the process + identified by <c><anno>Dest</anno></c>. Apart from + the format of the time-out message, this function works exactly as + <seealso marker="#start_timer/4"> + <c>erlang:start_timer/4</c></seealso>.</p> </desc> </func> <func> <name name="send_nosuspend" arity="2"/> - <fsummary>Tries to send a message without ever blocking.</fsummary> + <fsummary>Try to send a message without ever blocking.</fsummary> <type name="dst"/> <desc> <p>The same as - <seealso marker="#send/3">erlang:send(<anno>Dest</anno>, - <anno>Msg</anno>, [nosuspend])</seealso>, + <seealso marker="#send/3"><c>erlang:send(<anno>Dest</anno>, + <anno>Msg</anno>, [nosuspend])</c></seealso>, but returns <c>true</c> if the message was sent and <c>false</c> if the message was not sent because the sender would have had to be suspended.</p> @@ -5425,12 +5494,12 @@ true</pre> contradictory to the Erlang programming model. The message is <em>not</em> sent if this function returns <c>false</c>.</p> <p>In many systems, transient states of - overloaded queues are normal. The fact that this function + overloaded queues are normal. Although this function returns <c>false</c> does not mean that the other node is guaranteed to be non-responsive, it could be a temporary overload. Also, a return value of <c>true</c> does only mean that the message can be sent on the (TCP) channel - without blocking, the message is not guaranteed to + without blocking; the message is not guaranteed to arrive at the remote node. For a disconnected non-responsive node, the return value is <c>true</c> (mimics the behavior of operator <c>!</c>). The expected @@ -5444,15 +5513,16 @@ true</pre> <func> <name name="send_nosuspend" arity="3"/> - <fsummary>Tries to send a message without ever blocking.</fsummary> + <fsummary>Try to send a message without ever blocking.</fsummary> <type name="dst"/> <desc> <p>The same as - <seealso marker="#send/3">erlang:send(<anno>Dest</anno>, - <anno>Msg</anno>, [nosuspend | <anno>Options</anno>])</seealso>, + <seealso marker="#send/3"><c>erlang:send(<anno>Dest</anno>, + <anno>Msg</anno>, [nosuspend | <anno>Options</anno>])</c></seealso>, but with a Boolean return value.</p> <p>This function behaves like - <seealso marker="#send_nosuspend/2">erlang:send_nosuspend/2</seealso>, + <seealso marker="#send_nosuspend/2"> + <c>erlang:send_nosuspend/2</c></seealso>, but takes a third parameter, a list of options. The only option is <c>noconnect</c>, which makes the function return <c>false</c> if @@ -5476,14 +5546,15 @@ true</pre> <func> <name name="set_cookie" arity="2"/> - <fsummary>Sets the magic cookie of a node.</fsummary> + <fsummary>Set the magic cookie of a node.</fsummary> <desc> <p>Sets the magic cookie of <c><anno>Node</anno></c> to the atom <c><anno>Cookie</anno></c>. If <c><anno>Node</anno></c> is the local node, the function also sets the cookie of all other unknown nodes to - <c><anno>Cookie</anno></c> (see Section - <seealso marker="doc/reference_manual:distributed">Distributed Erlang</seealso> + <c><anno>Cookie</anno></c> (see section + <seealso marker="doc/reference_manual:distributed"> + Distributed Erlang</seealso> in the Erlang Reference Manual in System Documentation).</p> <p>Failure: <c>function_clause</c> if the local node is not alive.</p> @@ -5492,12 +5563,12 @@ true</pre> <func> <name name="setelement" arity="3"/> - <fsummary>Sets the Nth element of a tuple.</fsummary> + <fsummary>Set the Nth element of a tuple.</fsummary> <type_desc variable="Index">1..tuple_size(<anno>Tuple1</anno></type_desc> <desc> <p>Returns a tuple that is a copy of argument <c><anno>Tuple1</anno></c> - with the element given by integer argument + with the element specified by integer argument <c><anno>Index</anno></c> (the first element is the element with index 1) replaced by argument <c><anno>Value</anno></c>, for example:</p> @@ -5512,52 +5583,52 @@ true</pre> <fsummary>Size of a tuple or binary.</fsummary> <desc> <p>Returns the number of elements in a tuple or the number of - bytes in a binary or bitstring, for example:</p> + bytes in a binary or bitstring, for example:</p> <pre> > <input>size({morni, mulle, bwange}).</input> 3 > <input>size(<<11, 22, 33>>).</input> -3 -</pre> - <p>For bitstrings the number of whole bytes is returned. That is, if the number of bits +3</pre> + <p>For bitstrings, the number of whole bytes is returned. + That is, if the number of bits in the bitstring is not divisible by 8, the resulting number of bytes is rounded <em>down</em>.</p> <p>Allowed in guard tests.</p> <p>See also <seealso marker="#tuple_size/1"><c>tuple_size/1</c></seealso>, - <seealso marker="#byte_size/1"><c>byte_size/1</c></seealso> - and + <seealso marker="#byte_size/1"><c>byte_size/1</c></seealso>, and <seealso marker="#bit_size/1"><c>bit_size/1</c></seealso>.</p> </desc> </func> <func> <name name="spawn" arity="1"/> - <fsummary>Creates a new process with a fun as entry point.</fsummary> + <fsummary>Create a new process with a fun as entry point.</fsummary> <desc> <p>Returns the process identifier of a new process started by the application of <c><anno>Fun</anno></c> to the empty list <c>[]</c>. Otherwise - works like <seealso marker="#spawn/3">spawn/3</seealso>.</p> + works like <seealso marker="#spawn/3"><c>spawn/3</c></seealso>.</p> </desc> </func> <func> <name name="spawn" arity="2"/> - <fsummary>Creates a new process with a fun as entry point on a given node.</fsummary> + <fsummary>Create a new process with a fun as entry point on a specified + node.</fsummary> <desc> <p>Returns the process identifier of a new process started by the application of <c><anno>Fun</anno></c> to the empty list <c>[]</c> on <c><anno>Node</anno></c>. If <c><anno>Node</anno></c> does not exist, a useless pid is returned. Otherwise works like - <seealso marker="#spawn/3">spawn/3</seealso>.</p> + <seealso marker="#spawn/3"><c>spawn/3</c></seealso>.</p> </desc> </func> <func> <name name="spawn" arity="3"/> - <fsummary>Creates a new process with a function as entry point.</fsummary> + <fsummary>Create a new process with a function as entry point.</fsummary> <desc> <p>Returns the process identifier of a new process started by the application of <c><anno>Module</anno>:<anno>Function</anno></c> @@ -5569,7 +5640,7 @@ true</pre> does not exist (where <c>Arity</c> is the length of <c><anno>Args</anno></c>). The error handler can be redefined (see - <seealso marker="#process_flag/2">process_flag/2</seealso>). + <seealso marker="#process_flag/2"><c>process_flag/2</c></seealso>). If <c>error_handler</c> is undefined, or the user has redefined the default <c>error_handler</c> and its replacement is undefined, a failure with reason <c>undef</c> occurs.</p> @@ -5582,7 +5653,8 @@ true</pre> <func> <name name="spawn" arity="4"/> - <fsummary>Creates a new process with a function as entry point on a given node.</fsummary> + <fsummary>Create a new process with a function as entry point on a + specified node.</fsummary> <desc> <p>Returns the process identifier (pid) of a new process started by the application @@ -5590,26 +5662,28 @@ true</pre> to <c><anno>Args</anno></c> on <c><anno>Node</anno></c>. If <c><anno>Node</anno></c> does not exist, a useless pid is returned. Otherwise works like - <seealso marker="#spawn/3">spawn/3</seealso>.</p> + <seealso marker="#spawn/3"><c>spawn/3</c></seealso>.</p> </desc> </func> <func> <name name="spawn_link" arity="1"/> - <fsummary>Creates and links to a new process with a fun as entry point.</fsummary> + <fsummary>Create and link to a new process with a fun as entry point. + </fsummary> <desc> <p>Returns the process identifier of a new process started by the application of <c><anno>Fun</anno></c> to the empty list <c>[]</c>. A link is created between the calling process and the new process, atomically. Otherwise works like - <seealso marker="#spawn/3">spawn/3</seealso>.</p> + <seealso marker="#spawn/3"><c>spawn/3</c></seealso>.</p> </desc> </func> <func> <name name="spawn_link" arity="2"/> - <fsummary>Creates and links to a new process with a fun as entry point on a specified node.</fsummary> + <fsummary>Create and link to a new process with a fun as entry point on + a specified node.</fsummary> <desc> <p>Returns the process identifier (pid) of a new process started by the application of <c><anno>Fun</anno></c> to the empty @@ -5618,26 +5692,29 @@ true</pre> atomically. If <c><anno>Node</anno></c> does not exist, a useless pid is returned and an exit signal with reason <c>noconnection</c> is sent to the calling - process. Otherwise works like <seealso marker="#spawn/3">spawn/3</seealso>.</p> + process. Otherwise works like <seealso marker="#spawn/3"> + <c>spawn/3</c></seealso>.</p> </desc> </func> <func> <name name="spawn_link" arity="3"/> - <fsummary>Creates and links to a new process with a function as entry point.</fsummary> + <fsummary>Create and link to a new process with a function as entry point. + </fsummary> <desc> <p>Returns the process identifier of a new process started by the application of <c><anno>Module</anno>:<anno>Function</anno></c> to <c><anno>Args</anno></c>. A link is created between the calling process and the new process, atomically. Otherwise works like - <seealso marker="#spawn/3">spawn/3</seealso>.</p> + <seealso marker="#spawn/3"><c>spawn/3</c></seealso>.</p> </desc> </func> <func> <name name="spawn_link" arity="4"/> - <fsummary>Creates and links to a new process with a function as entry point on a given node.</fsummary> + <fsummary>Create and link to a new process with a function as entry point + on a specified node.</fsummary> <desc> <p>Returns the process identifier (pid) of a new process started by the application @@ -5647,109 +5724,113 @@ true</pre> process, atomically. If <c><anno>Node</anno></c> does not exist, a useless pid is returned and an exit signal with reason <c>noconnection</c> is sent to the calling - process. Otherwise works like <seealso marker="#spawn/3">spawn/3</seealso>.</p> + process. Otherwise works like <seealso marker="#spawn/3"> + <c>spawn/3</c></seealso>.</p> </desc> </func> <func> <name name="spawn_monitor" arity="1"/> - <fsummary>Creates and monitors a new process with a fun as entry point.</fsummary> + <fsummary>Create and monitor a new process with a fun as entry point. + </fsummary> <desc> <p>Returns the process identifier of a new process, started by the application of <c><anno>Fun</anno></c> to the empty list <c>[]</c>, and a reference for a monitor created to the new process. Otherwise works like - <seealso marker="#spawn/3">spawn/3</seealso>.</p> + <seealso marker="#spawn/3"><c>spawn/3</c></seealso>.</p> </desc> </func> <func> <name name="spawn_monitor" arity="3"/> - <fsummary>Creates and monitors a new process with a function as entry point.</fsummary> + <fsummary>Create and monitor a new process with a function as entry point. + </fsummary> <desc> <p>A new process is started by the application of <c><anno>Module</anno>:<anno>Function</anno></c> to <c><anno>Args</anno></c>. The process is monitored at the same time. Returns the process identifier and a reference for the monitor. Otherwise works like - <seealso marker="#spawn/3">spawn/3</seealso>.</p> + <seealso marker="#spawn/3"><c>spawn/3</c></seealso>.</p> </desc> </func> <func> <name name="spawn_opt" arity="2"/> - <fsummary>Creates a new process with a fun as entry point.</fsummary> + <fsummary>Create a new process with a fun as entry point.</fsummary> <type name="priority_level"/> - <type name="max_heap_size" /> - <type name="message_queue_data" /> - <type name="spawn_opt_option" /> + <type name="max_heap_size"/> + <type name="message_queue_data"/> + <type name="spawn_opt_option"/> <desc> <p>Returns the process identifier (pid) of a new process started by the application of <c><anno>Fun</anno></c> to the empty list <c>[]</c>. Otherwise works like - <seealso marker="#spawn_opt/4">spawn_opt/4</seealso>.</p> - <p>If option <c>monitor</c> is given, the newly created + <seealso marker="#spawn_opt/4"><c>spawn_opt/4</c></seealso>.</p> + <p>If option <c>monitor</c> is specified, the newly created process is monitored, and both the pid and reference for - the monitor is returned.</p> + the monitor are returned.</p> </desc> </func> <func> <name name="spawn_opt" arity="3"/> - <fsummary>Creates a new process with a fun as entry point on a given node.</fsummary> + <fsummary>Create a new process with a fun as entry point on a specified + node.</fsummary> <type name="priority_level"/> - <type name="max_heap_size" /> - <type name="message_queue_data" /> - <type name="spawn_opt_option" /> + <type name="max_heap_size"/> + <type name="message_queue_data"/> + <type name="spawn_opt_option"/> <desc> <p>Returns the process identifier (pid) of a new process started by the application of <c><anno>Fun</anno></c> to the empty list <c>[]</c> on <c><anno>Node</anno></c>. If <c><anno>Node</anno></c> does not exist, a useless pid is returned. Otherwise works like - <seealso marker="#spawn_opt/4">spawn_opt/4</seealso>.</p> + <seealso marker="#spawn_opt/4"><c>spawn_opt/4</c></seealso>.</p> </desc> </func> <func> <name name="spawn_opt" arity="4"/> - <fsummary>Creates a new process with a function as entry point.</fsummary> + <fsummary>Create a new process with a function as entry point.</fsummary> <type name="priority_level"/> - <type name="max_heap_size" /> - <type name="message_queue_data" /> - <type name="spawn_opt_option" /> + <type name="max_heap_size"/> + <type name="message_queue_data"/> + <type name="spawn_opt_option"/> <desc> <p>Works as - <seealso marker="#spawn/3">spawn/3</seealso>, except that an - extra option list is given when creating the process.</p> - <p>If option <c>monitor</c> is given, the newly created + <seealso marker="#spawn/3"><c>spawn/3</c></seealso>, except that an + extra option list is specified when creating the process.</p> + <p>If option <c>monitor</c> is specified, the newly created process is monitored, and both the pid and reference for - the monitor is returned.</p> - <p>The options are as follows:</p> + the monitor are returned.</p> + <p>Options:</p> <taglist> <tag><c>link</c></tag> <item> <p>Sets a link to the parent process (like - <c>spawn_link/3</c> does).</p> + <seealso marker="#spawn_link/3"><c>spawn_link/3</c></seealso> + does).</p> </item> <tag><c>monitor</c></tag> <item> <p>Monitors the new process (like - <seealso marker="#monitor/2">monitor/2</seealso> does).</p> + <seealso marker="#monitor/2"><c>monitor/2</c></seealso> does).</p> </item> <tag><c>{priority, <anno>Level</anno></c></tag> <item> <p>Sets the priority of the new process. Equivalent to - executing - <seealso marker="#process_flag_priority">process_flag(priority, - <anno>Level</anno>)</seealso> + executing <seealso marker="#process_flag_priority"> + <c>process_flag(priority, <anno>Level</anno>)</c></seealso> in the start function of the new process, except that the priority is set before the process is selected for execution for the first time. For more information on priorities, see - <seealso marker="#process_flag_priority">process_flag(priority, - <anno>Level</anno>)</seealso>.</p> + <seealso marker="#process_flag_priority"> + <c>process_flag(priority, <anno>Level</anno>)</c></seealso>.</p> </item> <tag><c>{fullsweep_after, <anno>Number</anno>}</c></tag> <item> @@ -5772,21 +5853,22 @@ true</pre> <p>A few cases when it can be useful to change <c>fullsweep_after</c>:</p> <list type="bulleted"> - <item>If binaries that are no longer used are to be + <item><p>If binaries that are no longer used are to be thrown away as soon as possible. (Set - <c><anno>Number</anno></c> to zero.) + <c><anno>Number</anno></c> to zero.)</p> </item> - <item>A process that mostly have short-lived data is + <item><p>A process that mostly have short-lived data is fullsweeped seldom or never, that is, the old heap contains mostly garbage. To ensure a fullsweep occasionally, set <c><anno>Number</anno></c> to a - suitable value, such as 10 or 20. + suitable value, such as 10 or 20.</p> </item> <item>In embedded systems with a limited amount of RAM and no virtual memory, you might want to preserve memory by setting <c><anno>Number</anno></c> to zero. (The value can be set globally, see - <seealso marker="#system_flag/2">erlang:system_flag/2</seealso>.) + <seealso marker="#system_flag/2"> + <c>erlang:system_flag/2</c></seealso>.) </item> </list> </item> @@ -5811,7 +5893,7 @@ true</pre> option unless you know that there is problem with execution times or memory consumption, and ensure that the option improves matters.</p> - <p>Gives a minimum binary virtual heap size, in words. + <p>Gives a minimum binary virtual heap size, in words. Setting this value higher than the system default can speed up some processes because less garbage collection is done. @@ -5823,24 +5905,25 @@ true</pre> <tag><c>{max_heap_size, <anno>Size</anno>}</c></tag> <item> <p>Sets the <c>max_heap_size</c> process flag. The default - <c>max_heap_size</c> is determined by the - <seealso marker="erl#+hmax"><c>+hmax</c></seealso> <c>erl</c> - command line argument. For more information, see the - documentation of - <seealso marker="#process_flag_max_heap_size"><c>process_flag(max_heap_size, - <anno>Size</anno>)</c></seealso>.</p> + <c>max_heap_size</c> is determined by command-line argument + <seealso marker="erl#+hmax"><c>+hmax</c></seealso> + in <c>erl(1)</c>. For more information, see the + documentation of <seealso marker="#process_flag_max_heap_size"> + <c>process_flag(max_heap_size, <anno>Size</anno>)</c></seealso>. + </p> </item> <tag><c>{message_queue_data, <anno>MQD</anno>}</c></tag> <item> <p>Sets the state of the <c>message_queue_data</c> process - flag. <c><anno>MQD</anno></c> should be either <c>off_heap</c>, - or <c>on_heap</c>. The default - <c>message_queue_data</c> process flag is determined by the - <seealso marker="erl#+hmqd"><c>+hmqd</c></seealso> <c>erl</c> - command line argument. For more information, see the - documentation of - <seealso marker="#process_flag_message_queue_data"><c>process_flag(message_queue_data, - <anno>MQD</anno>)</c></seealso>.</p> + flag. <c><anno>MQD</anno></c> is to be either <c>off_heap</c> + or <c>on_heap</c>. The default + <c>message_queue_data</c> process flag is determined by + command-line argument <seealso marker="erl#+hmqd"> + <c>+hmqd</c></seealso> in <c>erl(1)</c>. + For more information, see the documentation of + <seealso marker="#process_flag_message_queue_data"> + <c>process_flag(message_queue_data, + <anno>MQD</anno>)</c></seealso>.</p> </item> </taglist> </desc> @@ -5848,11 +5931,12 @@ true</pre> <func> <name name="spawn_opt" arity="5"/> - <fsummary>Creates a new process with a function as entry point on a given node.</fsummary> + <fsummary>Create a new process with a function as entry point on a + specified node.</fsummary> <type name="priority_level"/> - <type name="max_heap_size" /> - <type name="message_queue_data" /> - <type name="spawn_opt_option" /> + <type name="max_heap_size"/> + <type name="message_queue_data"/> + <type name="spawn_opt_option"/> <desc> <p>Returns the process identifier (pid) of a new process started by the application @@ -5860,23 +5944,24 @@ true</pre> <c><anno>Args</anno></c> on <c><anno>Node</anno></c>. If <c><anno>Node</anno></c> does not exist, a useless pid is returned. Otherwise works like - <seealso marker="#spawn_opt/4">spawn_opt/4</seealso>.</p> - <note><p>Option <c>monitor</c> is not supported by - <c>spawn_opt/5</c>.</p></note> + <seealso marker="#spawn_opt/4"><c>spawn_opt/4</c></seealso>.</p> + <note> + <p>Option <c>monitor</c> is not supported by + <c>spawn_opt/5</c>.</p> + </note> </desc> </func> <func> <name name="split_binary" arity="2"/> - <fsummary>Splits a binary into two.</fsummary> + <fsummary>Split a binary into two.</fsummary> <type_desc variable="Pos">0..byte_size(Bin)</type_desc> <desc> <p>Returns a tuple containing the binaries that are the result of splitting <c><anno>Bin</anno></c> into two parts at position <c><anno>Pos</anno></c>. This is not a destructive operation. After the operation, - there are three binaries altogether.</p> - <p>Example:</p> + there are three binaries altogether. Example:</p> <pre> > <input>B = list_to_binary("0123456789").</input> <<"0123456789">> @@ -5892,104 +5977,96 @@ true</pre> </func> <func> + <name name="start_timer" arity="3"/> + <fsummary>Start a timer.</fsummary> + <desc> + <p>Starts a timer. The same as calling + <seealso marker="#start_timer/4"> + <c>erlang:start_timer(<anno>Time</anno>, + <anno>Dest</anno>, <anno>Msg</anno>, [])</c></seealso>.</p> + </desc> + </func> + + <func> <name name="start_timer" arity="4"/> - <fsummary>Starts a timer.</fsummary> + <fsummary>Start a timer.</fsummary> <desc> - <p> - Starts a timer. When the timer expires, the message + <p>Starts a timer. When the timer expires, the message <c>{timeout, <anno>TimerRef</anno>, <anno>Msg</anno>}</c> - is sent to the process identified by - <c><anno>Dest</anno></c>. - </p> - <p>Available <c><anno>Option</anno></c>s:</p> + is sent to the process identified by <c><anno>Dest</anno></c>.</p> + <p><c><anno>Option</anno></c>s:</p> <taglist> <tag><c>{abs, false}</c></tag> <item> - <p> - This is the default. It means the - <c><anno>Time</anno></c> value is interpreted - as a time in milli-seconds <em>relative</em> current - <seealso marker="time_correction#Erlang_Monotonic_Time">Erlang - monotonic time</seealso>. - </p> - </item> + <p>This is the default. It means the + <c><anno>Time</anno></c> value is interpreted + as a time in milliseconds <em>relative</em> current + <seealso marker="time_correction#Erlang_Monotonic_Time">Erlang + monotonic time</seealso>.</p> + </item> <tag><c>{abs, true}</c></tag> <item> - <p> - Absolute <c><anno>Time</anno></c> value. The - <c><anno>Time</anno></c> value is interpreted as an - absolute Erlang monotonic time in milli-seconds. - </p> - </item> + <p>Absolute <c><anno>Time</anno></c> value. The + <c><anno>Time</anno></c> value is interpreted as an + absolute Erlang monotonic time in milliseconds.</p> + </item> </taglist> - <p> - More <c><anno>Option</anno></c>s may be added in the future. - </p> - <p> - The absolute point in time, the timer is set to expire on, - has to be in the interval - <c>[</c><seealso marker="#system_info_start_time"><c>erlang:system_info(start_time)</c></seealso><c>, - </c><seealso marker="#system_info_end_time"><c>erlang:system_info(end_time)</c></seealso><c>]</c>. - Further, if a relative time is specified, the <c><anno>Time</anno></c> value - is not allowed to be negative. - </p> - <p> - If <c><anno>Dest</anno></c> is a <c>pid()</c>, it must - be a <c>pid()</c> of a process created on the current - runtime system instance. This process may or may not - have terminated. If <c><anno>Dest</anno></c> is an - <c>atom()</c>, it is interpreted as the name of a - locally registered process. The process referred to by the - name is looked up at the time of timer expiration. No error - is given if the name does not refer to a process. - </p> - <p> - If <c><anno>Dest</anno></c> is a <c>pid()</c>, the timer is - automatically canceled if the process referred to by the - <c>pid()</c> is not alive, or if the process exits. This - feature was introduced in ERTS version 5.4.11. Notice that - timers are not automatically canceled when - <c><anno>Dest</anno></c> is an <c>atom()</c>. - </p> + <p>More <c><anno>Option</anno></c>s can be added in the future.</p> + <p>The absolute point in time, the timer is set to expire on, + must be in the interval + <c>[</c><seealso marker="#system_info_start_time"> + <c>erlang:system_info(start_time)</c></seealso><c>, + </c><seealso marker="#system_info_end_time"> + <c>erlang:system_info(end_time)</c></seealso><c>]</c>. + If a relative time is specified, the <c><anno>Time</anno></c> + value is not allowed to be negative.</p> + <p>If <c><anno>Dest</anno></c> is a <c>pid()</c>, it must + be a <c>pid()</c> of a process created on the current + runtime system instance. This process has either terminated + or not. If <c><anno>Dest</anno></c> is an + <c>atom()</c>, it is interpreted as the name of a + locally registered process. The process referred to by the + name is looked up at the time of timer expiration. No error + is returned if the name does not refer to a process.</p> + <p>If <c><anno>Dest</anno></c> is a <c>pid()</c>, the timer is + automatically canceled if the process referred to by the + <c>pid()</c> is not alive, or if the process exits. This + feature was introduced in <c>ERTS</c> 5.4.11. Notice that + timers are not automatically canceled when + <c><anno>Dest</anno></c> is an <c>atom()</c>.</p> <p>See also <seealso marker="#send_after/4"><c>erlang:send_after/4</c></seealso>, - <seealso marker="#cancel_timer/2"><c>erlang:cancel_timer/2</c></seealso>, - and - <seealso marker="#read_timer/2"><c>erlang:read_timer/2</c></seealso>.</p> + <seealso marker="#cancel_timer/2"> + <c>erlang:cancel_timer/2</c></seealso>, and + <seealso marker="#read_timer/2"> + <c>erlang:read_timer/2</c></seealso>.</p> <p>Failure: <c>badarg</c> if the arguments do not satisfy the requirements specified here.</p> </desc> </func> <func> - <name name="start_timer" arity="3"/> - <fsummary>Starts a timer.</fsummary> - <desc> - <p>Starts a timer. The same as calling - <seealso marker="#start_timer/4"><c>erlang:start_timer(<anno>Time</anno>, - <anno>Dest</anno>, <anno>Msg</anno>, [])</c></seealso>.</p> - </desc> - </func> - - <func> <name name="statistics" arity="1" clause_i="1"/> <fsummary>Information about active processes and ports.</fsummary> - <desc><marker id="statistics_active_tasks"></marker> - <p> - Returns a list where each element represents the amount - of active processes and ports on each run queue and its - associated scheduler. That is, the number of processes and - ports that are ready to run, or are currently running. The - element location in the list corresponds to the scheduler - and its run queue. The first element corresponds to scheduler - number 1 and so on. The information is <em>not</em> gathered - atomically. That is, the result is not necessarily a - consistent snapshot of the state, but instead quite - efficiently gathered. See also, - <seealso marker="#statistics_total_active_tasks"><c>statistics(total_active_tasks)</c></seealso>, - <seealso marker="#statistics_run_queue_lengths"><c>statistics(run_queue_lengths)</c></seealso>, and - <seealso marker="#statistics_total_run_queue_lengths"><c>statistics(total_run_queue_lengths)</c></seealso>. - </p> + <desc> + <marker id="statistics_active_tasks"></marker> + <p>Returns a list where each element represents the amount + of active processes and ports on each run queue and its + associated scheduler. That is, the number of processes and + ports that are ready to run, or are currently running. The + element location in the list corresponds to the scheduler + and its run queue. The first element corresponds to scheduler + number 1 and so on. The information is <em>not</em> gathered + atomically. That is, the result is not necessarily a + consistent snapshot of the state, but instead quite + efficiently gathered.</p> + <p>See also + <seealso marker="#statistics_total_active_tasks"> + <c>statistics(total_active_tasks)</c></seealso>, + <seealso marker="#statistics_run_queue_lengths"> + <c>statistics(run_queue_lengths)</c></seealso>, and + <seealso marker="#statistics_total_run_queue_lengths"> + <c>statistics(total_run_queue_lengths)</c></seealso>.</p> </desc> </func> @@ -6008,11 +6085,13 @@ true</pre> <desc> <marker id="statistics_exact_reductions"></marker> <p>Returns the number of exact reductions.</p> - <note><p><c>statistics(exact_reductions)</c> is - a more expensive operation than - <seealso marker="#statistics_reductions">statistics(reductions)</seealso>, - especially on an Erlang machine with SMP support.</p> - </note> + <note> + <p><c>statistics(exact_reductions)</c> is + a more expensive operation than + <seealso marker="#statistics_reductions"> + statistics(reductions)</seealso>, + especially on an Erlang machine with SMP support.</p> + </note> </desc> </func> @@ -6021,7 +6100,7 @@ true</pre> <fsummary>Information about garbage collection.</fsummary> <desc> <p>Returns information about garbage collection, for example:</p> - <pre> + <pre> > <input>statistics(garbage_collection).</input> {85,23961,0}</pre> <p>This information can be invalid for some implementations.</p> @@ -6033,9 +6112,9 @@ true</pre> <fsummary>Information about I/O.</fsummary> <desc> <p>Returns <c><anno>Input</anno></c>, - which is the total number of bytes - received through ports, and <c><anno>Output</anno></c>, - which is the total number of bytes output to ports.</p> + which is the total number of bytes + received through ports, and <c><anno>Output</anno></c>, + which is the total number of bytes output to ports.</p> </desc> </func> @@ -6044,23 +6123,21 @@ true</pre> <fsummary>Information about microstate accounting.</fsummary> <desc> <marker id="statistics_microstate_accounting"></marker> - <p> - Microstate accounting can be used to measure how much time the Erlang + <p>Microstate accounting can be used to measure how much time the Erlang runtime system spends doing various tasks. It is designed to be as - lightweight as possible, but there will be some overhead when this + lightweight as possible, but some overhead exists when this is enabled. Microstate accounting is meant to be a profiling tool - to help figure out performance bottlenecks. - To <c>start</c>/<c>stop</c>/<c>reset</c> microstate_accounting you use - the system_flag - <seealso marker="#system_flag_microstate_accounting"> - <c>microstate_accounting</c></seealso>. - </p> - <p> - <c>erlang:statistics(microstate_accounting)</c> returns a list of maps - representing some of the OS threads within ERTS. Each map contains - <c>type</c> and <c>id</c> fields that can be used to identify what + to help finding performance bottlenecks. + To <c>start</c>/<c>stop</c>/<c>reset</c> microstate accounting, use + system flag <seealso marker="#system_flag_microstate_accounting"> + <c>microstate_accounting</c></seealso>.</p> + <p><c>statistics(microstate_accounting)</c> returns a list of maps + representing some of the OS threads within <c>ERTS</c>. Each map + contains <c>type</c> and <c>id</c> fields that can be used to + identify what thread it is, and also a counters field that contains data about how much time has been spent in the various states.</p> + <p>Example:</p> <pre> > <input>erlang:statistics(microstate_accounting).</input> [#{counters => #{aux => 1899182914, @@ -6071,12 +6148,11 @@ true</pre> port => 221631, sleep => 5150294100}, id => 1, - type => scheduler}|...] - </pre> + type => scheduler}|...]</pre> <p>The time unit is the same as returned by - <seealso marker="kernel:os#perf_counter/0"> + <seealso marker="kernel:os#perf_counter/0"> <c>os:perf_counter/0</c></seealso>. - So to convert it to milliseconds you could do something like this:</p> + So, to convert it to milliseconds, you can do something like this:</p> <pre> lists:map( fun(#{ counters := Cnt } = M) -> @@ -6084,39 +6160,40 @@ lists:map( erlang:convert_time_unit(PerfCount, perf_counter, 1000) end, Cnt), M#{ counters := MsCnt } - end, erlang:statistics(microstate_accounting)). - </pre> - <p> - It is important to note that these values are not guaranteed to be + end, erlang:statistics(microstate_accounting)).</pre> + <p>Notice that these values are not guaranteed to be the exact time spent in each state. This is because of various - optimisation done in order to keep the overhead as small as possible. - </p> - - <p>Currently the following <c><anno>MSAcc_Thread_Type</anno></c> are available:</p> + optimisation done to keep the overhead as small as possible.</p> + <p><c><anno>MSAcc_Thread_Type</anno></c>s:</p> <taglist> <tag><c>scheduler</c></tag> <item>The main execution threads that do most of the work.</item> - <tag><c>async</c></tag><item>Async threads are used by various - linked-in drivers (mainly the file drivers) do offload non-cpu - intensive work.</item> - <tag><c>aux</c></tag><item>Takes care of any work that is not - specifically assigned to a scheduler.</item> + <tag><c>dirty_cpu_scheduler</c></tag> + <item>The threads for long running cpu intensive work.</item> + <tag><c>dirty_io_scheduler</c></tag> + <item>The threads for long running I/O work.</item> + <tag><c>async</c></tag> + <item>Async threads are used by various linked-in drivers (mainly the + file drivers) do offload non-CPU intensive work.</item> + <tag><c>aux</c></tag> + <item>Takes care of any work that is not + specifically assigned to a scheduler.</item> </taglist> - <p>Currently the following <c><anno>MSAcc_Thread_State</anno></c>s are available. - All states are exclusive, meaning that a thread cannot be in two states - at once. So if you add the numbers of all counters in a thread - you will get the total run-time for that thread.</p> + <p>The following <c><anno>MSAcc_Thread_State</anno></c>s are available. + All states are exclusive, meaning that a thread cannot be in two + states at once. So, if you add the numbers of all counters in a + thread, you get the total runtime for that thread.</p> <taglist> <tag><c>aux</c></tag> <item>Time spent handling auxiliary jobs.</item> <tag><c>check_io</c></tag> <item>Time spent checking for new I/O events.</item> <tag><c>emulator</c></tag> - <item>Time spent executing erlang processes.</item> + <item>Time spent executing Erlang processes.</item> <tag><c>gc</c></tag> <item>Time spent doing garbage collection. When extra states are - enabled this is the time spent doing non-fullsweep garbage - collections.</item> + enabled this is the time spent doing non-fullsweep garbage + collections.</item> <tag><c>other</c></tag> <item>Time spent doing unaccounted things.</item> <tag><c>port</c></tag> @@ -6124,61 +6201,59 @@ lists:map( <tag><c>sleep</c></tag> <item>Time spent sleeping.</item> </taglist> - <p>It is possible to add more fine grained <c><anno>MSAcc_Thread_State</anno></c>s - through configure. - (e.g. <c>./configure --with-microstate-accounting=extra</c>). - Enabling these states will cause a performance degradation when - microstate accounting is turned off and increase the overhead when - it is turned on.</p> + <p>More fine-grained <c><anno>MSAcc_Thread_State</anno></c>s can + be added through configure (such as + <c>./configure --with-microstate-accounting=extra</c>). + Enabling these states causes performance degradation when + microstate accounting is turned off and increases the overhead when + it is turned on.</p> <taglist> <tag><c>alloc</c></tag> <item>Time spent managing memory. Without extra states this time is - spread out over all other states.</item> + spread out over all other states.</item> <tag><c>bif</c></tag> - <item>Time spent in bifs. Without extra states this time is part of - the <c>emulator</c> state.</item> + <item>Time spent in BIFs. Without extra states this time is part of + the <c>emulator</c> state.</item> <tag><c>busy_wait</c></tag> <item>Time spent busy waiting. This is also the state where a - scheduler no longer reports that it is active when using - <seealso marker="#statistics_scheduler_wall_time"> - <c>erlang:statistics(scheduler_wall_time)</c></seealso>. - So if you add all other states but this and sleep and then divide that - by all time in the thread you should get something very similar to the - scheduler_wall_time fraction. Without extra states this time is part - of the <c>other</c> state.</item> + scheduler no longer reports that it is active when using + <seealso marker="#statistics_scheduler_wall_time"> + <c>statistics(scheduler_wall_time)</c></seealso>. So, if you add + all other states but this and sleep, and then divide that by all + time in the thread, you should get something very similar to the + <c>scheduler_wall_time</c> fraction. Without extra states this + time is part of the <c>other</c> state.</item> <tag><c>ets</c></tag> - <item>Time spent executing ETS bifs. Without extra states this time is - part of the <c>emulator</c> state.</item> + <item>Time spent executing <c>ets</c> BIFs. Without extra states + this time is part of the <c>emulator</c> state.</item> <tag><c>gc_full</c></tag> <item>Time spent doing fullsweep garbage collection. Without extra - states this time is part of the <c>gc</c> state.</item> + states this time is part of the <c>gc</c> state.</item> <tag><c>nif</c></tag> - <item>Time spent in nifs. Without extra states this time is part of - the <c>emulator</c> state.</item> + <item>Time spent in NIFs. Without extra states this time is part of + the <c>emulator</c> state.</item> <tag><c>send</c></tag> <item>Time spent sending messages (processes only). Without extra - states this time is part of the <c>emulator</c> state.</item> + states this time is part of the <c>emulator</c> state.</item> <tag><c>timers</c></tag> <item>Time spent managing timers. Without extra states this time is - part of the <c>other</c> state.</item> + part of the <c>other</c> state.</item> </taglist> - <p>There is a utility module called - <seealso marker="runtime_tools:msacc"><c>msacc</c></seealso> in - runtime_tools that can be used to more easily analyse these - statistics.</p> - - <p> - Returns <c>undefined</c> if the system flag + <p>The utility module + <seealso marker="runtime_tools:msacc"><c>runtime_tools:msacc(3)</c></seealso> + can be used to more easily analyse these statistics.</p> + <p>Returns <c>undefined</c> if system flag <seealso marker="#system_flag_microstate_accounting"> - <c>microstate_accounting</c></seealso> - is turned off. - </p> - <p>The list of thread information is unsorted and may appear in - different order between calls.</p> - <note><p>The threads and states are subject to change without any - prior notice.</p></note> + <c>microstate_accounting</c></seealso> is turned off.</p> + <p>The list of thread information is unsorted and can appear in + different order between calls.</p> + <note> + <p>The threads and states are subject to change without any + prior notice.</p> + </note> </desc> </func> + <func> <name name="statistics" arity="1" clause_i="7"/> <fsummary>Information about reductions.</fsummary> @@ -6188,11 +6263,12 @@ lists:map( <pre> > <input>statistics(reductions).</input> {2046,11}</pre> - <note><p>As from <c>ERTS</c> 5.5 (OTP R11B), + <note><p>As from <c>ERTS</c> 5.5 (Erlang/OTP R11B), this value does not include reductions performed in current time slices of currently scheduled processes. If an exact value is wanted, use - <seealso marker="#statistics_exact_reductions">statistics(exact_reductions)</seealso>.</p> + <seealso marker="#statistics_exact_reductions"> + <c>statistics(exact_reductions)</c></seealso>.</p> </note> </desc> </func> @@ -6201,15 +6277,14 @@ lists:map( <name name="statistics" arity="1" clause_i="8"/> <fsummary>Information about the run-queues.</fsummary> <desc><marker id="statistics_run_queue"></marker> - <p> - Returns the total length of the run-queues. That is, the number + <p>Returns the total length of the run-queues. That is, the number of processes and ports that are ready to run on all available - run-queues. The information is gathered atomically. That - is, the result is a consistent snapshot of the state, but - this operation is much more expensive compared to - <seealso marker="#statistics_total_run_queue_lengths"><c>statistics(total_run_queue_lengths)</c></seealso>. - This especially when a large amount of schedulers is used. - </p> + run-queues. The information is gathered atomically. That + is, the result is a consistent snapshot of the state, but + this operation is much more expensive compared to + <seealso marker="#statistics_total_run_queue_lengths"> + <c>statistics(total_run_queue_lengths)</c></seealso>, + especially when a large amount of schedulers is used.</p> </desc> </func> @@ -6217,19 +6292,21 @@ lists:map( <name name="statistics" arity="1" clause_i="9"/> <fsummary>Information about the run-queue lengths.</fsummary> <desc><marker id="statistics_run_queue_lengths"></marker> - <p> - Returns a list where each element represents the amount - of processes and ports ready to run for each run queue. The - element location in the list corresponds to the run queue - of a scheduler. The first element corresponds to the run - queue of scheduler number 1 and so on. The information is - <em>not</em> gathered atomically. That is, the result is - not necessarily a consistent snapshot of the state, but - instead quite efficiently gathered. See also, - <seealso marker="#statistics_total_run_queue_lengths"><c>statistics(total_run_queue_lengths)</c></seealso>, - <seealso marker="#statistics_active_tasks"><c>statistics(active_tasks)</c></seealso>, and - <seealso marker="#statistics_total_active_tasks"><c>statistics(total_active_tasks)</c></seealso>. - </p> + <p>Returns a list where each element represents the amount + of processes and ports ready to run for each run queue. The + element location in the list corresponds to the run queue + of a scheduler. The first element corresponds to the run + queue of scheduler number 1 and so on. The information is + <em>not</em> gathered atomically. That is, the result is + not necessarily a consistent snapshot of the state, but + instead quite efficiently gathered.</p> + <p>See also + <seealso marker="#statistics_total_run_queue_lengths"> + <c>statistics(total_run_queue_lengths)</c></seealso>, + <seealso marker="#statistics_active_tasks"> + <c>statistics(active_tasks)</c></seealso>, and + <seealso marker="#statistics_total_active_tasks"> + <c>statistics(total_active_tasks)</c></seealso>.</p> </desc> </func> @@ -6239,8 +6316,8 @@ lists:map( <desc> <p>Returns information about runtime, in milliseconds.</p> <p>This is the sum of the runtime for all threads - in the Erlang runtime system and can therefore be greater - than the wall clock time.</p> + in the Erlang runtime system and can therefore be greater + than the wall clock time.</p> <p>Example:</p> <pre> > <input>statistics(runtime).</input> @@ -6252,7 +6329,7 @@ lists:map( <name name="statistics" arity="1" clause_i="11"/> <fsummary>Information about each schedulers work time.</fsummary> <desc> - <marker id="statistics_scheduler_wall_time"></marker> + <marker id="statistics_scheduler_wall_time"></marker> <p>Returns a list of tuples with <c>{<anno>SchedulerId</anno>, <anno>ActiveTime</anno>, <anno>TotalTime</anno>}</c>, where @@ -6260,7 +6337,8 @@ lists:map( <c><anno>ActiveTime</anno></c> is the duration the scheduler has been busy, and <c><anno>TotalTime</anno></c> is the total time duration since - <seealso marker="#system_flag_scheduler_wall_time">scheduler_wall_time</seealso> + <seealso marker="#system_flag_scheduler_wall_time"> + <c>scheduler_wall_time</c></seealso> activation. The time unit is undefined and can be subject to change between releases, OSs, and system restarts. <c>scheduler_wall_time</c> is only to be used to @@ -6272,28 +6350,28 @@ lists:map( that is:</p> <list type="bulleted"> <item>Executing process code</item> - <item>Executing linked-in-driver or NIF code</item> - <item>Executing built-in-functions, or any other runtime - handling</item> + <item>Executing linked-in driver or NIF code</item> + <item>Executing BIFs, or any other runtime handling</item> <item>Garbage collecting</item> <item>Handling any other memory management</item> </list> - <p>Notice that a scheduler can also be busy even if the - OS has scheduled out the scheduler thread.</p> + <p>Notice that a scheduler can also be busy even if the + OS has scheduled out the scheduler thread.</p> <p>Returns <c>undefined</c> if system flag - <seealso marker="#system_flag_scheduler_wall_time">scheduler_wall_time</seealso> - is turned off.</p> + <seealso marker="#system_flag_scheduler_wall_time"> + <c>scheduler_wall_time</c></seealso> is turned off.</p> <p>The list of scheduler information is unsorted and can appear in different order between calls.</p> - <p>Using <c>scheduler_wall_time</c> to calculate scheduler-utilization:</p> -<pre> + <p>Using <c>scheduler_wall_time</c> to calculate + scheduler-utilization:</p> + <pre> > <input>erlang:system_flag(scheduler_wall_time, true).</input> false > <input>Ts0 = lists:sort(erlang:statistics(scheduler_wall_time)), ok.</input> ok</pre> <p>Some time later the user takes another snapshot and calculates scheduler-utilization per scheduler, for example:</p> -<pre> + <pre> > <input>Ts1 = lists:sort(erlang:statistics(scheduler_wall_time)), ok.</input> ok > <input>lists:map(fun({{I, A0, T0}, {I, A1, T1}}) -> @@ -6306,8 +6384,9 @@ ok {6,0.9739235846420741}, {7,0.973237033077876}, {8,0.9741297293248656}]</pre> - <p>Using the same snapshots to calculate a total scheduler-utilization:</p> -<pre> + <p>Using the same snapshots to calculate a total + scheduler-utilization:</p> + <pre> > <input>{A, T} = lists:foldl(fun({{_, A0, T0}, {_, A1, T1}}, {Ai,Ti}) -> {Ai + (A1 - A0), Ti + (T1 - T0)} end, {0, 0}, lists:zip(Ts0,Ts1)), A/T.</input> 0.9769136803764825</pre> @@ -6323,17 +6402,19 @@ ok <name name="statistics" arity="1" clause_i="12"/> <fsummary>Information about active processes and ports.</fsummary> <desc><marker id="statistics_total_active_tasks"></marker> - <p> - Returns the total amount of active processes and ports in - the system. That is, the number of processes and ports that - are ready to run, or are currently running. The information - is <em>not</em> gathered atomically. That is, the result - is not necessarily a consistent snapshot of the state, but - instead quite efficiently gathered. See also, - <seealso marker="#statistics_active_tasks"><c>statistics(active_tasks)</c></seealso>, - <seealso marker="#statistics_run_queue_lengths"><c>statistics(run_queue_lengths)</c></seealso>, and - <seealso marker="#statistics_total_run_queue_lengths"><c>statistics(total_run_queue_lengths)</c></seealso>. - </p> + <p>Returns the total amount of active processes and ports in + the system. That is, the number of processes and ports that + are ready to run, or are currently running. The information + is <em>not</em> gathered atomically. That is, the result + is not necessarily a consistent snapshot of the state, but + instead quite efficiently gathered.</p> + <p>See also + <seealso marker="#statistics_active_tasks"> + <c>statistics(active_tasks)</c></seealso>, + <seealso marker="#statistics_run_queue_lengths"> + <c>statistics(run_queue_lengths)</c></seealso>, and + <seealso marker="#statistics_total_run_queue_lengths"> + <c>statistics(total_run_queue_lengths)</c></seealso>.</p> </desc> </func> @@ -6341,18 +6422,19 @@ ok <name name="statistics" arity="1" clause_i="13"/> <fsummary>Information about the run-queue lengths.</fsummary> <desc><marker id="statistics_total_run_queue_lengths"></marker> - <p> - Returns the total length of the run-queues. That is, the number + <p>Returns the total length of the run queues. That is, the number of processes and ports that are ready to run on all available - run-queues. The information is <em>not</em> gathered atomically. - That is, the result is not necessarily a consistent snapshot of - the state, but much more efficiently gathered compared to - <seealso marker="#statistics_run_queue"><c>statistics(run_queue)</c></seealso>. - See also, - <seealso marker="#statistics_run_queue_lengths"><c>statistics(run_queue_lengths)</c></seealso>, - <seealso marker="#statistics_total_active_tasks"><c>statistics(total_active_tasks)</c></seealso>, and - <seealso marker="#statistics_active_tasks"><c>statistics(active_tasks)</c></seealso>. - </p> + run queues. The information is <em>not</em> gathered atomically. + That is, the result is not necessarily a consistent snapshot of + the state, but much more efficiently gathered compared to + <seealso marker="#statistics_run_queue"> + <c>statistics(run_queue)</c></seealso>.</p> + <p>See also <seealso marker="#statistics_run_queue_lengths"> + <c>statistics(run_queue_lengths)</c></seealso>, + <seealso marker="#statistics_total_active_tasks"> + <c>statistics(total_active_tasks)</c></seealso>, and + <seealso marker="#statistics_active_tasks"> + <c>statistics(active_tasks)</c></seealso>.</p> </desc> </func> @@ -6368,64 +6450,80 @@ ok </func> <func> + <name name="suspend_process" arity="1"/> + <fsummary>Suspend a process.</fsummary> + <desc> + <p>Suspends the process identified by + <c><anno>Suspendee</anno></c>. The same as calling + <seealso marker="#suspend_process/2"> + <c>erlang:suspend_process(<anno>Suspendee</anno>, + [])</c></seealso>.</p> + <warning> + <p>This BIF is intended for debugging only.</p> + </warning> + </desc> + </func> + + <func> <name name="suspend_process" arity="2"/> - <fsummary>Suspends a process.</fsummary> + <fsummary>Suspend a process.</fsummary> <desc> <p>Increases the suspend count on the process identified by - <c><anno>Suspendee</anno></c> and puts it in the suspended - state if it is not - already in that state. A suspended process will not be - scheduled for execution until the process has been resumed.</p> - <p>A process can be suspended by multiple processes and can - be suspended multiple times by a single process. A suspended - process does not leave the suspended state until its suspend - count reaches zero. The suspend count of - <c><anno>Suspendee</anno></c> is decreased when - <seealso marker="#resume_process/1">erlang:resume_process(<anno>Suspendee</anno>)</seealso> - is called by the same process that called - <c>erlang:suspend_process(<anno>Suspendee</anno>)</c>. - All increased suspend - counts on other processes acquired by a process are automatically - decreased when the process terminates.</p> - <p>The options (<c><anno>Opt</anno></c>s) are as follows:</p> + <c><anno>Suspendee</anno></c> and puts it in the suspended + state if it is not + already in that state. A suspended process is not + scheduled for execution until the process has been resumed.</p> + <p>A process can be suspended by multiple processes and can + be suspended multiple times by a single process. A suspended + process does not leave the suspended state until its suspend + count reaches zero. The suspend count of + <c><anno>Suspendee</anno></c> is decreased when + <seealso marker="#resume_process/1"> + <c>erlang:resume_process(<anno>Suspendee</anno>)</c></seealso> + is called by the same process that called + <c>erlang:suspend_process(<anno>Suspendee</anno>)</c>. + All increased suspend + counts on other processes acquired by a process are automatically + decreased when the process terminates.</p> + <p>Options (<c><anno>Opt</anno></c>s):</p> <taglist> <tag><c>asynchronous</c></tag> <item> - A suspend request is sent to the process identified by - <c><anno>Suspendee</anno></c>. <c><anno>Suspendee</anno></c> - eventually suspends - unless it is resumed before it could suspend. The caller - of <c>erlang:suspend_process/2</c> returns immediately, - regardless of whether <c><anno>Suspendee</anno></c> has - suspended yet or not. The point in time when - <c><anno>Suspendee</anno></c> suspends cannot be deduced - from other events in the system. It is only guaranteed that - <c><anno>Suspendee</anno></c> <em>eventually</em> suspends - (unless it - is resumed). If option <c>asynchronous</c> has <em>not</em> - been passed, the caller of <c>erlang:suspend_process/2</c> is - blocked until <c><anno>Suspendee</anno></c> has suspended. - </item> + <p>A suspend request is sent to the process identified by + <c><anno>Suspendee</anno></c>. <c><anno>Suspendee</anno></c> + eventually suspends + unless it is resumed before it could suspend. The caller + of <c>erlang:suspend_process/2</c> returns immediately, + regardless of whether <c><anno>Suspendee</anno></c> has + suspended yet or not. The point in time when + <c><anno>Suspendee</anno></c> suspends cannot be deduced + from other events in the system. It is only guaranteed that + <c><anno>Suspendee</anno></c> <em>eventually</em> suspends + (unless it + is resumed). If option <c>asynchronous</c> has <em>not</em> + been passed, the caller of <c>erlang:suspend_process/2</c> is + blocked until <c><anno>Suspendee</anno></c> has suspended.</p> + </item> <tag><c>unless_suspending</c></tag> <item> - The process identified by <c><anno>Suspendee</anno></c> is - suspended unless the calling process already is suspending - <c><anno>Suspendee</anno></c>. - If <c>unless_suspending</c> is combined - with option <c>asynchronous</c>, a suspend request is - sent unless the calling process already is suspending - <c><anno>Suspendee</anno></c> or if a suspend request - already has been sent and is in transit. If the calling - process already is suspending <c><anno>Suspendee</anno></c>, - or if combined with option <c>asynchronous</c> - and a send request already is in transit, - <c>false</c> is returned and the suspend count on - <c><anno>Suspendee</anno></c> remains unchanged. - </item> + <p>The process identified by <c><anno>Suspendee</anno></c> is + suspended unless the calling process already is suspending + <c><anno>Suspendee</anno></c>. + If <c>unless_suspending</c> is combined + with option <c>asynchronous</c>, a suspend request is + sent unless the calling process already is suspending + <c><anno>Suspendee</anno></c> or if a suspend request + already has been sent and is in transit. If the calling + process already is suspending <c><anno>Suspendee</anno></c>, + or if combined with option <c>asynchronous</c> + and a send request already is in transit, + <c>false</c> is returned and the suspend count on + <c><anno>Suspendee</anno></c> remains unchanged.</p> + </item> </taglist> - <p>If the suspend count on the process identified by - <c><anno>Suspendee</anno></c> is increased, <c>true</c> - is returned, otherwise <c>false</c>.</p> + <p>If the suspend count on the process identified by + <c><anno>Suspendee</anno></c> is increased, <c>true</c> + is returned, otherwise <c>false</c>.</p> <warning> <p>This BIF is intended for debugging only.</p> </warning> @@ -6433,58 +6531,44 @@ ok <taglist> <tag><c>badarg</c></tag> <item> - If <c><anno>Suspendee</anno></c> is not a process identifier. - </item> + If <c><anno>Suspendee</anno></c> is not a process identifier. + </item> <tag><c>badarg</c></tag> <item> - If the process identified by <c><anno>Suspendee</anno></c> - is the same process - as the process calling <c>erlang:suspend_process/2</c>. - </item> + If the process identified by <c><anno>Suspendee</anno></c> + is the same process + as the process calling <c>erlang:suspend_process/2</c>. + </item> <tag><c>badarg</c></tag> <item> - If the process identified by <c><anno>Suspendee</anno></c> - is not alive. - </item> + If the process identified by <c><anno>Suspendee</anno></c> + is not alive. + </item> <tag><c>badarg</c></tag> <item> - If the process identified by <c><anno>Suspendee</anno></c> - resides on another node. - </item> + If the process identified by <c><anno>Suspendee</anno></c> + resides on another node. + </item> <tag><c>badarg</c></tag> <item> - If <c><anno>OptList</anno></c> is not a proper list of valid - <c><anno>Opt</anno></c>s. - </item> + If <c><anno>OptList</anno></c> is not a proper list of valid + <c><anno>Opt</anno></c>s. + </item> <tag><c>system_limit</c></tag> <item> - If the process identified by <c><anno>Suspendee</anno></c> - has been suspended - more times by the calling process than can be represented by the - currently used internal data structures. The system limit is - higher than 2,000,000,000 suspends and will never be lower. - </item> + If the process identified by <c><anno>Suspendee</anno></c> + has been suspended + more times by the calling process than can be represented by the + currently used internal data structures. The system limit is + > 2,000,000,000 suspends and will never be lower. + </item> </taglist> </desc> </func> <func> - <name name="suspend_process" arity="1"/> - <fsummary>Suspends a process.</fsummary> - <desc> - <p>Suspends the process identified by - <c><anno>Suspendee</anno></c>. The same as calling - <seealso marker="#suspend_process/2">erlang:suspend_process(<anno>Suspendee</anno>, - [])</seealso>.</p> - <warning> - <p>This BIF is intended for debugging only.</p> - </warning> - </desc> - </func> - - <func> <name name="system_flag" arity="2" clause_i="1"/> - <fsummary>Sets system flag <c>backtrace_depth</c>.</fsummary> + <fsummary>Set system flag <c>backtrace_depth</c>.</fsummary> <desc> <p>Sets the maximum depth of call stack back-traces in the exit reason element of <c>'EXIT'</c> tuples.</p> @@ -6494,7 +6578,7 @@ ok <func> <name name="system_flag" arity="2" clause_i="2"/> - <fsummary>Sets system flag <c>cpu_topology</c>.</fsummary> + <fsummary>Set system flag <c>cpu_topology</c>.</fsummary> <type name="cpu_topology"/> <type name="level_entry"/> <type name="level_tag"/> @@ -6503,52 +6587,52 @@ ok <desc> <warning> <p><marker id="system_flag_cpu_topology"></marker> - This argument is <em>deprecated</em> and scheduled for - removal in <c>ERTS</c> 5.10/OTP R16. Instead of using this - argument, use command-line argument - <seealso marker="erts:erl#+sct">+sct</seealso> in - <c>erl(1)</c>.</p> + <em>This argument is deprecated.</em> + Instead of using this argument, use command-line argument + <seealso marker="erts:erl#+sct"><c>+sct</c></seealso> in + <c>erl(1)</c>.</p> <p>When this argument is removed, a final CPU topology - to use is determined at emulator boot time.</p> + to use is determined at emulator boot time.</p> </warning> <p>Sets the user-defined <c><anno>CpuTopology</anno></c>. - The user-defined - CPU topology overrides any automatically detected - CPU topology. By passing <c>undefined</c> as - <c><anno>CpuTopology</anno></c>, - the system reverts to the CPU topology automatically - detected. The returned value equals the value returned - from <c>erlang:system_info(cpu_topology)</c> before the - change was made.</p> + The user-defined + CPU topology overrides any automatically detected + CPU topology. By passing <c>undefined</c> as + <c><anno>CpuTopology</anno></c>, + the system reverts to the CPU topology automatically + detected. The returned value equals the value returned + from <c>erlang:system_info(cpu_topology)</c> before the + change was made.</p> <p>Returns the old value of the flag.</p> <p>The CPU topology is used when binding schedulers to logical - processors. If schedulers are already bound when the CPU - topology is changed, the schedulers are sent a request - to rebind according to the new CPU topology.</p> + processors. If schedulers are already bound when the CPU + topology is changed, the schedulers are sent a request + to rebind according to the new CPU topology.</p> <p>The user-defined CPU topology can also be set by passing - command-line argument - <seealso marker="erts:erl#+sct">+sct</seealso> to - <c>erl(1)</c>.</p> + command-line argument + <seealso marker="erts:erl#+sct"><c>+sct</c></seealso> to + <c>erl(1)</c>.</p> <p>For information on type <c><anno>CpuTopology</anno></c> - and more, see - <seealso marker="#system_info_cpu_topology">erlang:system_info(cpu_topology)</seealso> - as well as the command-line flags - <seealso marker="erts:erl#+sct">+sct</seealso> and - <seealso marker="erts:erl#+sbt">+sbt</seealso> in - <c>erl(1)</c>.</p> + and more, see + <seealso marker="#system_info_cpu_topology"> + <c>erlang:system_info(cpu_topology)</c></seealso> + as well as command-line flags + <seealso marker="erts:erl#+sct"><c>+sct</c></seealso> and + <seealso marker="erts:erl#+sbt"><c>+sbt</c></seealso> in + <c>erl(1)</c>.</p> </desc> </func> <func> <name name="system_flag" arity="2" clause_i="3"/> - <fsummary>Sets <c>system_flag_dirty_cpu_schedulers_online</c>.</fsummary> + <fsummary>Set system_flag_dirty_cpu_schedulers_online.</fsummary> <desc> <p><marker id="system_flag_dirty_cpu_schedulers_online"></marker> - Sets the number of dirty CPU schedulers online. Range is - <![CDATA[1 <= DirtyCPUSchedulersOnline <= N]]>, where <c>N</c> - is the smallest of the return values of - <c>erlang:system_info(dirty_cpu_schedulers)</c> and - <c>erlang:system_info(schedulers_online)</c>.</p> + Sets the number of dirty CPU schedulers online. Range is + <c><![CDATA[1 <= DirtyCPUSchedulersOnline <= N]]></c>, where <c>N</c> + is the smallest of the return values of + <c>erlang:system_info(dirty_cpu_schedulers)</c> and + <c>erlang:system_info(schedulers_online)</c>.</p> <p>Returns the old value of the flag.</p> <p>The number of dirty CPU schedulers online can change if the number of schedulers online changes. For example, if 12 @@ -6559,20 +6643,22 @@ ok down to 3. Similarly, the number of dirty CPU schedulers online increases proportionally to increases in the number of schedulers online.</p> - <note><p>The dirty schedulers functionality is experimental. - Enable support for dirty schedulers when building OTP to - try out the functionality.</p> + <note> + <p>The dirty schedulers functionality is experimental. + Enable support for dirty schedulers when building OTP to + try out the functionality.</p> </note> <p>For more information, see - <seealso marker="#system_info_dirty_cpu_schedulers">erlang:system_info(dirty_cpu_schedulers)</seealso> - and - <seealso marker="#system_info_dirty_cpu_schedulers_online">erlang:system_info(dirty_cpu_schedulers_online)</seealso>.</p> + <seealso marker="#system_info_dirty_cpu_schedulers"> + <c>erlang:system_info(dirty_cpu_schedulers)</c></seealso> and + <seealso marker="#system_info_dirty_cpu_schedulers_online"> + <c>erlang:system_info(dirty_cpu_schedulers_online)</c></seealso>.</p> </desc> </func> <func> <name name="system_flag" arity="2" clause_i="4"/> - <fsummary>Sets system flag <c>fullsweep_after</c>.</fsummary> + <fsummary>Set system flag fullsweep_after.</fsummary> <desc> <p>Sets system flag <c>fullsweep_after</c>. <c><anno>Number</anno></c> is a non-negative integer indicating @@ -6591,43 +6677,45 @@ ok <func> <name name="system_flag" arity="2" clause_i="5"/> - <fsummary>Set system flag microstate_accounting</fsummary> - <desc><p><marker id="system_flag_microstate_accounting"></marker> - Turns on/off microstate accounting measurements. By passing reset it is possible to reset - all counters to 0.</p> - <p>For more information see, - <seealso marker="#statistics_microstate_accounting">erlang:statistics(microstate_accounting)</seealso>. - </p> + <fsummary>Set system flag microstate_accounting.</fsummary> + <desc> + <p><marker id="system_flag_microstate_accounting"></marker> + Turns on/off microstate accounting measurements. When passing reset, + all counters are reset to 0.</p> + <p>For more information see + <seealso marker="#statistics_microstate_accounting"> + <c>statistics(microstate_accounting)</c></seealso>.</p> </desc> </func> + <func> <name name="system_flag" arity="2" clause_i="6"/> - <fsummary>Sets system flag <c>min_heap_size</c>.</fsummary> + <fsummary>Set system flag min_heap_size.</fsummary> <desc> <p>Sets the default minimum heap size for processes. The size - is given in words. The new <c>min_heap_size</c> effects + is specified in words. The new <c>min_heap_size</c> effects only processes spawned after the change of <c>min_heap_size</c> has been made. <c>min_heap_size</c> can be set for individual processes by using - <seealso marker="#spawn_opt/4">spawn_opt/N</seealso> or - <seealso marker="#process_flag/2">process_flag/2</seealso>.</p> + <seealso marker="#spawn_opt/4"><c>spawn_opt/4</c></seealso> or + <seealso marker="#process_flag/2"><c>process_flag/2</c></seealso>.</p> <p>Returns the old value of the flag.</p> </desc> </func> <func> <name name="system_flag" arity="2" clause_i="7"/> - <fsummary>Sets system flag <c>min_bin_vheap_size</c>.</fsummary> + <fsummary>Set system flag min_bin_vheap_size.</fsummary> <desc> <p>Sets the default minimum binary virtual heap size for - processes. The size is given in words. + processes. The size is specified in words. The new <c>min_bin_vhheap_size</c> effects only processes spawned after the change of - <c>min_bin_vhheap_size</c> has been made. + <c>min_bin_vheap_size</c> has been made. <c>min_bin_vheap_size</c> can be set for individual processes by using - <seealso marker="#spawn_opt/4">spawn_opt/N</seealso> or - <seealso marker="#process_flag/2">process_flag/2</seealso>.</p> + <seealso marker="#spawn_opt/4"><c>spawn_opt/2,3,4</c></seealso> or + <seealso marker="#process_flag/2"><c>process_flag/2</c></seealso>.</p> <p>Returns the old value of the flag.</p> </desc> </func> @@ -6635,232 +6723,251 @@ ok <marker id="system_flag_max_heap_size"></marker> <func> <name name="system_flag" arity="2" clause_i="8"/> - <fsummary>Sets system flag <c>max_heap_size</c></fsummary> + <fsummary>Set system flag max_heap_size.</fsummary> <type name="max_heap_size"/> <desc> <p> Sets the default maximum heap size settings for processes. - The size is given in words. The new <c>max_heap_size</c> + The size is specified in words. The new <c>max_heap_size</c> effects only processes spawned efter the change has been made. <c>max_heap_size</c> can be set for individual processes using - <seealso marker="#spawn_opt/4">spawn_opt/N</seealso> or - <seealso marker="#process_flag_message_queue_data">process_flag/2</seealso>.</p> + <seealso marker="#spawn_opt/4"><c>spawn_opt/2,3,4</c></seealso> or + <seealso marker="#process_flag_message_queue_data"> + <c>process_flag/2</c></seealso>.</p> <p>Returns the old value of the flag.</p> </desc> </func> <func> <name name="system_flag" arity="2" clause_i="9"/> - <fsummary>Sets system flag <c>multi_scheduling</c>.</fsummary> + <fsummary>Set system flag multi_scheduling.</fsummary> <desc> <p><marker id="system_flag_multi_scheduling"></marker> If multi-scheduling is enabled, more than one scheduler thread is used by the emulator. Multi-scheduling can be blocked in two different ways. Either all schedulers but - one is blocked, or all <em>normal</em> schedulers but - one is blocked. When only normal schedulers are blocked - dirty schedulers are free to continue to schedule - processes.</p> + one is blocked, or all <em>normal</em> schedulers but + one is blocked. When only normal schedulers are blocked, + dirty schedulers are free to continue to schedule + processes.</p> <p>If <c><anno>BlockState</anno> =:= block</c>, multi-scheduling is blocked. That is, one and only one scheduler thread will - execute. If <c><anno>BlockState</anno> =:= unblock</c> and no one + execute. If <c><anno>BlockState</anno> =:= unblock</c> and no one else blocks multi-scheduling, and this process has blocked only once, multi-scheduling is unblocked.</p> <p>If <c><anno>BlockState</anno> =:= block_normal</c>, normal - multi-scheduling is blocked. That is, only one normal scheduler - thread will execute, but multiple dirty schedulers may execute. - If <c><anno>BlockState</anno> =:= unblock_normal</c> and no one + multi-scheduling is blocked. That is, only one normal scheduler + thread will execute, but multiple dirty schedulers can execute. + If <c><anno>BlockState</anno> =:= unblock_normal</c> and no one else blocks normal multi-scheduling, and this process has blocked only once, normal multi-scheduling is unblocked.</p> - <p>One process can block multi-scheduling as well as normal - multi-scheduling multiple times. If a process has blocked - multiple times, it must unblock exactly as many times as it - has blocked before it has released its multi-scheduling - block. If a process that has blocked multi-scheduling or normal - multi scheduling exits, it automatically releases its blocking - of multi-scheduling and normal multi-scheduling.</p> + <p>One process can block multi-scheduling and normal + multi-scheduling multiple times. If a process has blocked + multiple times, it must unblock exactly as many times as it + has blocked before it has released its multi-scheduling + block. If a process that has blocked multi-scheduling or normal + multi-scheduling exits, it automatically releases its blocking + of multi-scheduling and normal multi-scheduling.</p> <p>The return values are <c>disabled</c>, <c>blocked</c>, <c>blocked_normal</c>, or <c>enabled</c>. The returned value - describes the state just after the call to + describes the state just after the call to <c>erlang:system_flag(multi_scheduling, <anno>BlockState</anno>)</c> has been made. For information about the return values, see - <seealso marker="#system_info_multi_scheduling">erlang:system_info(multi_scheduling)</seealso>.</p> + <seealso marker="#system_info_multi_scheduling"> + <c>erlang:system_info(multi_scheduling)</c></seealso>.</p> <note><p>Blocking of multi-scheduling and normal multi-scheduling - is normally not needed. If you feel that you need to use these - features, consider it a few more times again. Blocking - multi-scheduling is only to be used as a last resort, as it is - most likely a <em>very inefficient</em> way to solve the problem.</p> + is normally not needed. If you feel that you need to use these + features, consider it a few more times again. Blocking + multi-scheduling is only to be used as a last resort, as it is + most likely a <em>very inefficient</em> way to solve the problem.</p> </note> <p>See also - <seealso marker="#system_info_multi_scheduling">erlang:system_info(multi_scheduling)</seealso>, - <seealso marker="#system_info_normal_multi_scheduling_blockers">erlang:system_info(normal_multi_scheduling_blockers)</seealso>, - <seealso marker="#system_info_multi_scheduling_blockers">erlang:system_info(multi_scheduling_blockers)</seealso>, and - <seealso marker="#system_info_schedulers">erlang:system_info(schedulers)</seealso>.</p> + <seealso marker="#system_info_multi_scheduling"> + <c>erlang:system_info(multi_scheduling)</c></seealso>, + <seealso marker="#system_info_normal_multi_scheduling_blockers"> + <c>erlang:system_info(normal_multi_scheduling_blockers)</c></seealso>, + <seealso marker="#system_info_multi_scheduling_blockers"> + <c>erlang:system_info(multi_scheduling_blockers)</c></seealso>, and + <seealso marker="#system_info_schedulers"> + <c>erlang:system_info(schedulers)</c></seealso>.</p> </desc> </func> <func> <name name="system_flag" arity="2" clause_i="10"/> - <fsummary>Sets system flag <c>scheduler_bind_type</c>.</fsummary> + <fsummary>Set system flag scheduler_bind_type.</fsummary> <type name="scheduler_bind_type"/> <desc> <warning> <p><marker id="system_flag_scheduler_bind_type"></marker> - This argument is <em>deprecated</em> and scheduled for - removal in <c>ERTS</c> 5.10/OTP R16. Instead of using this - argument, use command-line argument - <seealso marker="erts:erl#+sbt">+sbt</seealso> in <c>erl(1)</c>. - When this argument is removed, a final scheduler bind - type to use is determined at emulator boot time.</p> + <em>This argument is deprecated.</em> + Instead of using this argument, use command-line argument + <seealso marker="erts:erl#+sbt"><c>+sbt</c></seealso> in + <c>erl(1)</c>. When this argument is removed, a final scheduler bind + type to use is determined at emulator boot time.</p> </warning> <p>Controls if and how schedulers are bound to logical - processors.</p> + processors.</p> <p>When <c>erlang:system_flag(scheduler_bind_type, <anno>How</anno>)</c> - is called, an asynchronous signal is sent to all schedulers - online, causing them to try to bind or unbind as requested.</p> + is called, an asynchronous signal is sent to all schedulers + online, causing them to try to bind or unbind as requested.</p> <note><p>If a scheduler fails to bind, this is often silently - ignored, as it is not always possible to verify valid - logical processor identifiers. If an error is reported, - it is reported to <c>error_logger</c>. To verify that the - schedulers have bound as requested, call - <seealso marker="#system_info_scheduler_bindings">erlang:system_info(scheduler_bindings)</seealso>.</p> + ignored, as it is not always possible to verify valid + logical processor identifiers. If an error is reported, + it is reported to <c>error_logger</c>. To verify that the + schedulers have bound as requested, call + <seealso marker="#system_info_scheduler_bindings"> + <c>erlang:system_info(scheduler_bindings)</c></seealso>.</p> </note> <p>Schedulers can be bound on newer Linux, - Solaris, FreeBSD, and Windows systems, but more systems will be - supported in future releases.</p> + Solaris, FreeBSD, and Windows systems, but more systems will be + supported in future releases.</p> <p>In order for the runtime system to be able to bind schedulers, - the CPU topology must be known. If the runtime system fails - to detect the CPU topology automatically, it can be defined. - For more information on how to define the CPU topology, see - command-line flag <seealso marker="erts:erl#+sct">+sct</seealso> - in <c>erl(1)</c>.</p> + the CPU topology must be known. If the runtime system fails + to detect the CPU topology automatically, it can be defined. + For more information on how to define the CPU topology, see + command-line flag <seealso marker="erts:erl#+sct"> + <c>+sct</c></seealso> in <c>erl(1)</c>.</p> <p>The runtime system does by default <em>not</em> bind schedulers - to logical processors.</p> + to logical processors.</p> <note><p>If the Erlang runtime system is the only OS - process binding threads to logical processors, this - improves the performance of the runtime system. However, - if other OS processes (for example, another Erlang - runtime system) also bind threads to logical processors, - there can be a performance penalty instead. Sometimes this - performance penalty can be severe. If so, it is recommended - to not bind the schedulers.</p> + process binding threads to logical processors, this + improves the performance of the runtime system. However, + if other OS processes (for example, another Erlang + runtime system) also bind threads to logical processors, + there can be a performance penalty instead. Sometimes this + performance penalty can be severe. If so, it is recommended + to not bind the schedulers.</p> </note> <p>Schedulers can be bound in different ways. Argument - <c><anno>How</anno></c> determines how schedulers are - bound and can be any of the following:</p> + <c><anno>How</anno></c> determines how schedulers are + bound and can be any of the following:</p> <taglist> <tag><c>unbound</c></tag> - <item><p>Same as command-line argument - <seealso marker="erts:erl#+sbt">+sbt u</seealso> in <c>erl(1)</c>. - </p></item> + <item>Same as command-line argument + <seealso marker="erts:erl#+sbt"><c>+sbt u</c></seealso> in + <c>erl(1)</c>. + </item> <tag><c>no_spread</c></tag> - <item><p>Same as command-line argument - <seealso marker="erts:erl#+sbt">+sbt ns</seealso> in <c>erl(1)</c>. - </p></item> + <item>Same as command-line argument + <seealso marker="erts:erl#+sbt"><c>+sbt ns</c></seealso> + in <c>erl(1)</c>. + </item> <tag><c>thread_spread</c></tag> - <item><p>Same as command-line argument - <seealso marker="erts:erl#+sbt">+sbt ts</seealso> in <c>erl(1)</c>. - </p></item> + <item>Same as command-line argument + <seealso marker="erts:erl#+sbt"><c>+sbt ts</c></seealso> + in <c>erl(1)</c>. + </item> <tag><c>processor_spread</c></tag> - <item><p>Same as command-line argument - <seealso marker="erts:erl#+sbt">+sbt ps</seealso> in <c>erl(1)</c>. - </p></item> + <item>Same as command-line argument + <seealso marker="erts:erl#+sbt"><c>+sbt ps</c></seealso> + in <c>erl(1)</c>. + </item> <tag><c>spread</c></tag> - <item><p>Same as command-line argument - <seealso marker="erts:erl#+sbt">+sbt s</seealso> in <c>erl(1)</c>. - </p></item> + <item>Same as command-line argument + <seealso marker="erts:erl#+sbt"><c>+sbt s</c></seealso> + in <c>erl(1)</c>. + </item> <tag><c>no_node_thread_spread</c></tag> - <item><p>Same as command-line argument - <seealso marker="erts:erl#+sbt">+sbt nnts</seealso> in <c>erl(1)</c>. - </p></item> + <item>Same as command-line argument + <seealso marker="erts:erl#+sbt"><c>+sbt nnts</c></seealso> + in <c>erl(1)</c>. + </item> <tag><c>no_node_processor_spread</c></tag> - <item><p>Same as command-line argument - <seealso marker="erts:erl#+sbt">+sbt nnps</seealso> in <c>erl(1)</c>. - </p></item> + <item>Same as command-line argument + <seealso marker="erts:erl#+sbt"><c>+sbt nnps</c></seealso> + in <c>erl(1)</c>. + </item> <tag><c>thread_no_node_processor_spread</c></tag> - <item><p>Same as command-line argument - <seealso marker="erts:erl#+sbt">+sbt tnnps</seealso> in <c>erl(1)</c>. - </p></item> + <item>Same as command-line argument + <seealso marker="erts:erl#+sbt"><c>+sbt tnnps</c></seealso> + in <c>erl(1)</c>. + </item> <tag><c>default_bind</c></tag> - <item><p>Same as command-line argument - <seealso marker="erts:erl#+sbt">+sbt db</seealso> in <c>erl(1)</c>. - </p></item> + <item>Same as command-line argument + <seealso marker="erts:erl#+sbt"><c>+sbt db</c></seealso> + in <c>erl(1)</c>. + </item> </taglist> <p>The returned value equals <c><anno>How</anno></c> before flag <c>scheduler_bind_type</c> was changed.</p> <p>Failures:</p> <taglist> <tag><c>notsup</c></tag> - <item> - <p>If binding of schedulers is not supported.</p> + <item>If binding of schedulers is not supported. </item> <tag><c>badarg</c></tag> - <item> - <p>If <c><anno>How</anno></c> is not one of the documented - alternatives.</p> + <item>If <c><anno>How</anno></c> is not one of the documented + alternatives. </item> <tag><c>badarg</c></tag> - <item> - <p>If CPU topology information is unavailable.</p> + <item>If CPU topology information is unavailable. </item> </taglist> - <p>The scheduler bind type can also be set by passing - command-line argument - <seealso marker="erts:erl#+sbt">+sbt</seealso> to <c>erl(1)</c>.</p> + <p>The scheduler bind type can also be set by passing command-line + argument <seealso marker="erts:erl#+sbt"> + <c>+sbt</c></seealso> to <c>erl(1)</c>.</p> <p>For more information, see - <seealso marker="#system_info_scheduler_bind_type">erlang:system_info(scheduler_bind_type)</seealso>, - <seealso marker="#system_info_scheduler_bindings">erlang:system_info(scheduler_bindings)</seealso>, - as well as command-line flags - <seealso marker="erts:erl#+sbt">+sbt</seealso> - and <seealso marker="erts:erl#+sct">+sct</seealso> - in <c>erl(1)</c>.</p> + <seealso marker="#system_info_scheduler_bind_type"> + <c>erlang:system_info(scheduler_bind_type)</c></seealso>, + <seealso marker="#system_info_scheduler_bindings"> + <c>erlang:system_info(scheduler_bindings)</c></seealso>, + as well as command-line flags + <seealso marker="erts:erl#+sbt"><c>+sbt</c></seealso> + and <seealso marker="erts:erl#+sct"><c>+sct</c></seealso> + in <c>erl(1)</c>.</p> </desc> </func> <func> <name name="system_flag" arity="2" clause_i="11"/> - <fsummary>Sets system flag <c>scheduler_wall_time</c>.</fsummary> - <desc><p><marker id="system_flag_scheduler_wall_time"></marker> - Turns on or off scheduler wall time measurements.</p> - <p>For more information, see - <seealso marker="#statistics_scheduler_wall_time">erlang:statistics(scheduler_wall_time)</seealso>.</p> + <fsummary>Set system flag scheduler_wall_time.</fsummary> + <desc> + <p><marker id="system_flag_scheduler_wall_time"></marker> + Turns on or off scheduler wall time measurements.</p> + <p>For more information, see + <seealso marker="#statistics_scheduler_wall_time"> + <c>statistics(scheduler_wall_time)</c></seealso>.</p> </desc> </func> <func> <name name="system_flag" arity="2" clause_i="12"/> - <fsummary>Sets system flag <c>schedulers_online</c>.</fsummary> + <fsummary>Set system flag schedulers_online.</fsummary> <desc> <p><marker id="system_flag_schedulers_online"></marker> - Sets the number of schedulers online. Range is - <![CDATA[1 <= SchedulersOnline <= erlang:system_info(schedulers)]]>.</p> + Sets the number of schedulers online. Range is + <c><![CDATA[1 <= SchedulersOnline <= + erlang:system_info(schedulers)]]></c>.</p> <p>Returns the old value of the flag.</p> <p>If the emulator was built with support for - <seealso marker="#system_flag_dirty_cpu_schedulers_online">dirty schedulers</seealso>, - changing the number of schedulers online can also change the - number of dirty CPU schedulers online. For example, if 12 - schedulers and 6 dirty CPU schedulers are online, and - <c>system_flag/2</c> is used to set the number of schedulers - online to 6, then the number of dirty CPU schedulers online - is automatically decreased by half as well, down to 3. - Similarly, the number of dirty CPU schedulers online increases - proportionally to increases in the number of schedulers online.</p> + <seealso marker="#system_flag_dirty_cpu_schedulers_online"> + dirty schedulers</seealso>, + changing the number of schedulers online can also change the + number of dirty CPU schedulers online. For example, if 12 + schedulers and 6 dirty CPU schedulers are online, and + <c>system_flag/2</c> is used to set the number of schedulers + online to 6, then the number of dirty CPU schedulers online + is automatically decreased by half as well, down to 3. + Similarly, the number of dirty CPU schedulers online increases + proportionally to increases in the number of schedulers online.</p> <p>For more information, see - <seealso marker="#system_info_schedulers">erlang:system_info(schedulers)</seealso> - and - <seealso marker="#system_info_schedulers_online">erlang:system_info(schedulers_online)</seealso>.</p> + <seealso marker="#system_info_schedulers"> + <c>erlang:system_info(schedulers)</c></seealso> and + <seealso marker="#system_info_schedulers_online"> + <c>erlang:system_info(schedulers_online)</c></seealso>.</p> </desc> </func> <func> <name name="system_flag" arity="2" clause_i="13"/> - <fsummary>Sets system flag <c>trace_control_word</c>.</fsummary> + <fsummary>Set system flag trace_control_word.</fsummary> <desc> <p>Sets the value of the node trace control word to <c><anno>TCW</anno></c>, which is to be an unsigned integer. - For more information, see the function - <seealso marker="erts:match_spec#set_tcw">set_tcw</seealso> - in Section "Match Specifications in Erlang" in the + For more information, see function + <seealso marker="erts:match_spec#set_tcw"><c>set_tcw</c></seealso> + in section "Match Specifications in Erlang" in the User's Guide.</p> <p>Returns the old value of the flag.</p> </desc> @@ -6868,29 +6975,30 @@ ok <func> <name name="system_flag" arity="2" clause_i="14"/> - <fsummary>Finalize the Time Offset</fsummary> + <fsummary>Finalize the time offset.</fsummary> <desc> <p><marker id="system_flag_time_offset"></marker> - Finalizes the <seealso marker="#time_offset/0">time offset</seealso> - when <seealso marker="time_correction#Single_Time_Warp_Mode">single - time warp mode</seealso> is used. If another time warp mode - is used, the time offset state is left unchanged.</p> - <p>Returns the old state identifier. That is:</p> - <list> - <item><p>If <c>preliminary</c> is returned, finalization was - performed and the time offset is now final.</p></item> - - <item><p>If <c>final</c> is returned, the time offset was - already in the final state. This either because another - <c>erlang:system_flag(time_offset, finalize)</c> call, or - because <seealso marker="time_correction#No_Time_Warp_Mode">no - time warp mode</seealso> is used.</p></item> - - <item><p>If <c>volatile</c> is returned, the time offset - cannot be finalized because - <seealso marker="time_correction#Multi_Time_Warp_Mode">multi - time warp mode</seealso> is used.</p></item> - </list> + Finalizes the <seealso marker="#time_offset/0">time offset</seealso> + when <seealso marker="time_correction#Single_Time_Warp_Mode">single + time warp mode</seealso> is used. If another time warp mode + is used, the time offset state is left unchanged.</p> + <p>Returns the old state identifier, that is:</p> + <list> + <item><p>If <c>preliminary</c> is returned, finalization was + performed and the time offset is now final.</p> + </item> + <item><p>If <c>final</c> is returned, the time offset was + already in the final state. This either because another + <c>erlang:system_flag(time_offset, finalize)</c> call or + because <seealso marker="time_correction#No_Time_Warp_Mode">no + time warp mode</seealso> is used.</p> + </item> + <item><p>If <c>volatile</c> is returned, the time offset + cannot be finalized because + <seealso marker="time_correction#Multi_Time_Warp_Mode">multi-time + warp mode</seealso> is used.</p> + </item> + </list> </desc> </func> @@ -6907,7 +7015,7 @@ ok <type variable="Settings" name_i="2"/> <type variable="Alloc" name_i="3"/> <desc> - <marker id="system_info_allocator_tags"></marker> + <marker id="system_info_allocator_tags"></marker> <p>Returns various information about the allocators of the current system (emulator) as specified by <c><anno>Item</anno></c>:</p> @@ -6926,17 +7034,18 @@ ok <p><c>erlang:system_info(allocated_areas)</c> is intended for debugging, and the content is highly implementation-dependent. The content of the results - therefore changes when needed without prior notice.</p> + therefore changes when needed without prior notice.</p> <p>Notice that the sum of these values is <em>not</em> the total amount of memory allocated by the emulator. Some values are part of other values, and some memory areas are not part of the result. For information about the total amount of memory allocated by the emulator, see - <seealso marker="#memory/0">erlang:memory/0,1</seealso>.</p> + <seealso marker="#memory/0"> + <c>erlang:memory/0,1</c></seealso>.</p> </item> <tag><c>allocator</c></tag> <item> - <marker id="system_info_allocator"></marker> + <marker id="system_info_allocator"></marker> <p>Returns <c>{<anno>Allocator</anno>, <anno>Version</anno>, <anno>Features</anno>, <anno>Settings</anno></c>, where:</p> <list type="bulleted"> @@ -6966,27 +7075,30 @@ ok </item> </list> <p>See also "System Flags Effecting erts_alloc" in - <seealso marker="erts:erts_alloc#flags">erts_alloc(3)</seealso>.</p> + <seealso marker="erts:erts_alloc#flags"> + <c>erts_alloc(3)</c></seealso>.</p> </item> <tag><c>alloc_util_allocators</c></tag> <item> - <marker id="system_info_alloc_util_allocators"></marker> - <p>Returns a list of the names of all allocators using - the <c>ERTS</c> internal <c>alloc_util</c> framework - as atoms. For more information, see Section - <seealso marker="erts:erts_alloc#alloc_util">"The - alloc_util framework" in erts_alloc(3)</seealso>.</p> + <marker id="system_info_alloc_util_allocators"></marker> + <p>Returns a list of the names of all allocators using + the <c>ERTS</c> internal <c>alloc_util</c> framework + as atoms. For more information, see section + <seealso marker="erts:erts_alloc#alloc_util">The + alloc_util framework</seealso> + in <c>erts_alloc(3)</c>.</p> </item> <tag><c>{allocator, <anno>Alloc</anno>}</c></tag> <item> - <marker id="system_info_allocator_tuple"></marker> + <marker id="system_info_allocator_tuple"></marker> <p>Returns information about the specified allocator. - As from <c>ERTS</c> 5.6.1, the return value is a list - of <c>{instance, InstanceNo, InstanceInfo}</c> tuples, - where <c>InstanceInfo</c> contains information about - a specific instance of the allocator. If <c><anno>Alloc</anno></c> is not a - recognized allocator, <c>undefined</c> is returned. - If <c><anno>Alloc</anno></c> is disabled, + As from <c>ERTS</c> 5.6.1, the return value is a list + of <c>{instance, InstanceNo, InstanceInfo}</c> tuples, + where <c>InstanceInfo</c> contains information about + a specific instance of the allocator. + If <c><anno>Alloc</anno></c> is not a + recognized allocator, <c>undefined</c> is returned. + If <c><anno>Alloc</anno></c> is disabled, <c>false</c> is returned.</p> <p>Notice that the information returned is highly implementation-dependent and can be changed or removed @@ -6995,15 +7107,14 @@ ok as it can be of interest for others it has been briefly documented.</p> <p>The recognized allocators are listed in - <seealso marker="erts:erts_alloc">erts_alloc(3)</seealso>. - Information about super carriers can be obtained from - <c>ERTS</c> 8.0 with <c>{allocator, erts_mmap}</c> or from - <c>ERTS</c> 5.10.4, the returned list when calling with - <c>{allocator, mseg_alloc}</c> also includes an - <c>{erts_mmap, _}</c> tuple as one element in the list.</p> - + <seealso marker="erts:erts_alloc"><c>erts_alloc(3)</c></seealso>. + Information about super carriers can be obtained from + <c>ERTS</c> 8.0 with <c>{allocator, erts_mmap}</c> or from + <c>ERTS</c> 5.10.4; the returned list when calling with + <c>{allocator, mseg_alloc}</c> also includes an + <c>{erts_mmap, _}</c> tuple as one element in the list.</p> <p>After reading the <c>erts_alloc(3)</c> documentation, - the returned information + the returned information more or less speaks for itself, but it can be worth explaining some things. Call counts are presented by two values, the first value is giga calls, and the second @@ -7019,19 +7130,20 @@ ok <item>The third is the maximum value since the emulator was started.</item> </list> - <p>If only one value is present, it is the current value. + <p>If only one value is present, it is the current value. <c>fix_alloc</c> memory block types are presented by two values. The first value is the memory pool size and the second value is the used memory size.</p> </item> <tag><c>{allocator_sizes, <anno>Alloc</anno>}</c></tag> <item> - <marker id="system_info_allocator_sizes"></marker> - <p>Returns various size information for the specified - allocator. The information returned is a subset of the - information returned by - <seealso marker="#system_info_allocator_tuple"><c>erlang:system_info({allocator, <anno>Alloc</anno>})</c></seealso>. - </p> + <marker id="system_info_allocator_sizes"></marker> + <p>Returns various size information for the specified + allocator. The information returned is a subset of the + information returned by + <seealso marker="#system_info_allocator_tuple"> + <c>erlang:system_info({allocator, + <anno>Alloc</anno>})</c></seealso>.</p> </item> </taglist> </desc> @@ -7065,69 +7177,74 @@ ok The <c>info_list()</c> can be extended in a future release. </type_desc> <desc> - <marker id="system_info_cpu_topology_tags"></marker> - <marker id="system_info_cpu_topology"></marker> + <marker id="system_info_cpu_topology_tags"></marker> + <marker id="system_info_cpu_topology"></marker> <p>Returns various information about the CPU topology of the current system (emulator) as specified by <c><anno>Item</anno></c>:</p> <taglist> <tag><c>cpu_topology</c></tag> <item> - <p>Returns the <c><anno>CpuTopology</anno></c> currently used by - the emulator. The CPU topology is used when binding schedulers - to logical processors. The CPU topology used is the - <seealso marker="erlang#system_info_cpu_topology_defined">user-defined CPU topology</seealso>, - if such exists, otherwise the - <seealso marker="erlang#system_info_cpu_topology_detected">automatically detected CPU topology</seealso>, - if such exists. If no CPU topology - exists, <c>undefined</c> is returned.</p> - <p><c>node</c> refers to Non-Uniform Memory Access (NUMA) - nodes. <c>thread</c> refers to hardware threads - (for example, Intel hyper-threads).</p> + <p>Returns the <c><anno>CpuTopology</anno></c> currently used by + the emulator. The CPU topology is used when binding schedulers + to logical processors. The CPU topology used is the + <seealso marker="erlang#system_info_cpu_topology_defined"> + user-defined CPU topology</seealso>, + if such exists, otherwise the + <seealso marker="erlang#system_info_cpu_topology_detected"> + automatically detected CPU topology</seealso>, + if such exists. If no CPU topology + exists, <c>undefined</c> is returned.</p> + <p><c>node</c> refers to Non-Uniform Memory Access (NUMA) + nodes. <c>thread</c> refers to hardware threads + (for example, Intel hyper-threads).</p> <p>A level in term <c><anno>CpuTopology</anno></c> can be - omitted if only one entry exists and - <c><anno>InfoList</anno></c> is empty.</p> - <p><c>thread</c> can only be a sub level to <c>core</c>. - <c>core</c> can be a sub level to <c>processor</c> - or <c>node</c>. <c>processor</c> can be on the - top level or a sub level to <c>node</c>. <c>node</c> - can be on the top level or a sub level to - <c>processor</c>. That is, NUMA nodes can be processor - internal or processor external. A CPU topology can - consist of a mix of processor internal and external - NUMA nodes, as long as each logical CPU belongs to - <em>one</em> NUMA node. Cache hierarchy is not part of - the <c><anno>CpuTopology</anno></c> type, but will be in a - future release. Other things can also make it into the CPU - topology in a future release. In other words, expect the - <c><anno>CpuTopology</anno></c> type to change.</p> + omitted if only one entry exists and + <c><anno>InfoList</anno></c> is empty.</p> + <p><c>thread</c> can only be a sublevel to <c>core</c>. + <c>core</c> can be a sublevel to <c>processor</c> + or <c>node</c>. <c>processor</c> can be on the + top level or a sublevel to <c>node</c>. <c>node</c> + can be on the top level or a sublevel to + <c>processor</c>. That is, NUMA nodes can be processor + internal or processor external. A CPU topology can + consist of a mix of processor internal and external + NUMA nodes, as long as each logical CPU belongs to + <em>one</em> NUMA node. Cache hierarchy is not part of + the <c><anno>CpuTopology</anno></c> type, but will be in a + future release. Other things can also make it into the CPU + topology in a future release. So, expect the + <c><anno>CpuTopology</anno></c> type to change.</p> </item> <tag><c>{cpu_topology, defined}</c></tag> <item> - <marker id="system_info_cpu_topology_defined"></marker> + <marker id="system_info_cpu_topology_defined"></marker> <p>Returns the user-defined <c><anno>CpuTopology</anno></c>. - For more information, see command-line flag - <seealso marker="erts:erl#+sct">+sct</seealso> in - <c>erl(1)</c> and argument - <seealso marker="#system_info_cpu_topology">cpu_topology</seealso>.</p> + For more information, see command-line flag + <seealso marker="erts:erl#+sct"><c>+sct</c></seealso> in + <c>erl(1)</c> and argument + <seealso marker="#system_info_cpu_topology"> + <c>cpu_topology</c></seealso>.</p> </item> <tag><c>{cpu_topology, detected}</c></tag> <item> - <marker id="system_info_cpu_topology_detected"></marker> + <marker id="system_info_cpu_topology_detected"></marker> <p>Returns the automatically detected - <c><anno>CpuTopology</anno>y</c>. The - emulator detects the CPU topology on some newer - Linux, Solaris, FreeBSD, and Windows systems. - On Windows system with more than 32 logical processors, - the CPU topology is not detected.</p> + <c><anno>CpuTopology</anno>y</c>. The + emulator detects the CPU topology on some newer + Linux, Solaris, FreeBSD, and Windows systems. + On Windows system with more than 32 logical processors, + the CPU topology is not detected.</p> <p>For more information, see argument - <seealso marker="#system_info_cpu_topology">cpu_topology</seealso>.</p> + <seealso marker="#system_info_cpu_topology"> + <c>cpu_topology</c></seealso>.</p> </item> <tag><c>{cpu_topology, used}</c></tag> <item> <p>Returns <c><anno>CpuTopology</anno></c> used by the emulator. For more information, see argument - <seealso marker="#system_info_cpu_topology">cpu_topology</seealso>.</p> + <seealso marker="#system_info_cpu_topology"> + <c>cpu_topology</c></seealso>.</p> </item> </taglist> </desc> @@ -7144,13 +7261,14 @@ ok <type name="message_queue_data"/> <type name="max_heap_size"/> <desc> + <p>Returns information about the default process heap settings:</p> <taglist> <tag><c>fullsweep_after</c></tag> <item> <p>Returns <c>{fullsweep_after, integer() >= 0}</c>, which is the <c>fullsweep_after</c> garbage collection setting used by default. For more information, see - <c>garbage_collection</c> described in the following.</p> + <c>garbage_collection</c> described below.</p> </item> <tag><c>garbage_collection</c></tag> <item> @@ -7159,50 +7277,52 @@ ok <c>spawn</c> or <c>spawn_link</c> uses these garbage collection settings. The default settings can be changed by using - <seealso marker="#system_flag/2">system_flag/2</seealso>. - <seealso marker="#spawn_opt/4">spawn_opt/4</seealso> + <seealso marker="#system_flag/2"> + <c>erlang:system_flag/2</c></seealso>. + <seealso marker="#spawn_opt/4"><c>spawn_opt/2,3,4</c></seealso> can spawn a process that does not use the default settings.</p> </item> <tag><c>max_heap_size</c></tag> <item> - <p>Returns <c>{max_heap_size, <anno>MaxHeapSize</anno>}</c>, + <p>Returns <c>{max_heap_size, <anno>MaxHeapSize</anno>}</c>, where <c><anno>MaxHeapSize</anno></c> is the current - system-wide max heap size settings for spawned processes. - This setting can be set using the <c>erl</c> command line - flags <seealso marker="erl#+hmax"><c>+hmax</c></seealso>, + system-wide maximum heap size settings for spawned processes. + This setting can be set using the command-line flags + <seealso marker="erl#+hmax"><c>+hmax</c></seealso>, <seealso marker="erl#+hmaxk"><c>+hmaxk</c></seealso> and - <seealso marker="erl#+hmaxel"><c>+hmaxel</c></seealso>. It can - also be changed at run-time using + <seealso marker="erl#+hmaxel"><c>+hmaxel</c></seealso> in + <c>erl(1)</c>. It can also be changed at runtime using <seealso marker="#system_flag_max_heap_size"> - <c>erlang:system_flag(max_heap_size, MaxHeapSize)</c></seealso>. - For more details about the <c>max_heap_size</c> process flag + <c>erlang:system_flag(max_heap_size, MaxHeapSize)</c></seealso>. + For more details about the <c>max_heap_size</c> process flag, see <seealso marker="#process_flag_max_heap_size"> - <c>process_flag(max_heap_size, MaxHeapSize)</c></seealso>. - </p> + <c>process_flag(max_heap_size, MaxHeapSize)</c></seealso>.</p> </item> - <tag><c>min_heap_size</c></tag> + <tag><c>min_heap_size</c></tag> <item> - <p>Returns <c>{min_heap_size, <anno>MinHeapSize</anno>}</c>, + <p>Returns <c>{min_heap_size, <anno>MinHeapSize</anno>}</c>, where <c><anno>MinHeapSize</anno></c> is the current system-wide minimum heap size for spawned processes.</p> </item> - <tag><marker id="system_info_message_queue_data"/><c>message_queue_data</c></tag> + <tag><marker id="system_info_message_queue_data"/> + <c>message_queue_data</c></tag> <item> <p>Returns the default value of the <c>message_queue_data</c> - process flag which is either <c>off_heap</c>, or <c>on_heap</c>. - This default is set by the <c>erl</c> command line argument - <seealso marker="erl#+hmqd"><c>+hmqd</c></seealso>. For more information on the - <c>message_queue_data</c> process flag, see documentation of - <seealso marker="#process_flag_message_queue_data"><c>process_flag(message_queue_data, - MQD)</c></seealso>.</p> + process flag, which is either <c>off_heap</c> or <c>on_heap</c>. + This default is set by command-line argument + <seealso marker="erl#+hmqd"><c>+hmqd</c></seealso> in + <c>erl(1)</c>. For more information on the + <c>message_queue_data</c> process flag, see documentation of + <seealso marker="#process_flag_message_queue_data"> + <c>process_flag(message_queue_data, MQD)</c></seealso>.</p> </item> - <tag><c>min_bin_vheap_size</c></tag> + <tag><c>min_bin_vheap_size</c></tag> <item> - <p>Returns <c>{min_bin_vheap_size, + <p>Returns <c>{min_bin_vheap_size, <anno>MinBinVHeapSize</anno>}</c>, where <c><anno>MinBinVHeapSize</anno></c> is the current system-wide - minimum binary virtual heap size for spawned processes.</p> + minimum binary virtual heap size for spawned processes.</p> </item> </taglist> </desc> @@ -7273,24 +7393,25 @@ ok <tag><c>allocated_areas</c>, <c>allocator</c>, <c>alloc_util_allocators</c>, <c>allocator_sizes</c></tag> <item> - <p>See <seealso marker="#system_info_allocator_tags">above</seealso>.</p> + <p>See <seealso marker="#system_info_allocator_tags"> + above</seealso>.</p> </item> <tag><c>build_type</c></tag> <item> <p>Returns an atom describing the build type of the runtime - system. This is normally the atom <c>opt</c> for optimized. - Other possible return values are <c>debug</c>, <c>purify</c>, - <c>quantify</c>, <c>purecov</c>, <c>gcov</c>, <c>valgrind</c>, - <c>gprof</c>, and <c>lcnt</c>. Possible return values - can be added or removed at any time without prior notice.</p> + system. This is normally the atom <c>opt</c> for optimized. + Other possible return values are <c>debug</c>, <c>purify</c>, + <c>quantify</c>, <c>purecov</c>, <c>gcov</c>, <c>valgrind</c>, + <c>gprof</c>, and <c>lcnt</c>. Possible return values + can be added or removed at any time without prior notice.</p> </item> <tag><c>c_compiler_used</c></tag> <item> <p>Returns a two-tuple describing the C compiler used when - compiling the runtime system. The first element is an - atom describing the name of the compiler, or <c>undefined</c> - if unknown. The second element is a term describing the - version of the compiler, or <c>undefined</c> if unknown.</p> + compiling the runtime system. The first element is an + atom describing the name of the compiler, or <c>undefined</c> + if unknown. The second element is a term describing the + version of the compiler, or <c>undefined</c> if unknown.</p> </item> <tag><c>check_io</c></tag> <item> @@ -7307,12 +7428,13 @@ ok Erlang/OTP release that the current emulator has been set to be backward compatible with. The compatibility mode can be configured at startup by using command-line flag - <seealso marker="erts:erl#compat_rel">+R</seealso> in + <seealso marker="erts:erl#compat_rel"><c>+R</c></seealso> in <c>erl(1)</c>.</p> </item> <tag><c>cpu_topology</c></tag> <item> - <p>See <seealso marker="#system_info_cpu_topology_tags">above</seealso>.</p> + <p>See <seealso + marker="#system_info_cpu_topology_tags">above</seealso>.</p> </item> <tag><c>creation</c></tag> <item> @@ -7328,22 +7450,22 @@ ok </item> <tag><c>debug_compiled</c></tag> <item> - <p>Returns <c>true</c> if the emulator has been debug - compiled, otherwise <c>false</c>.</p> + <p>Returns <c>true</c> if the emulator has been + debug-compiled, otherwise <c>false</c>.</p> </item> <tag><c>delayed_node_table_gc</c></tag> <item> <marker id="system_info_delayed_node_table_gc"></marker> <p>Returns the amount of time in seconds garbage collection - of an entry in a node table is delayed. This limit can be set - on startup by passing the command line flag - <seealso marker="erts:erl#+zdntgc">+zdntgc</seealso> - to <c>erl</c>. For more information see the documentation of the - command line flag.</p> + of an entry in a node table is delayed. This limit can be set + on startup by passing command-line flag + <seealso marker="erts:erl#+zdntgc"><c>+zdntgc</c></seealso> + to <c>erl(1)</c>. For more information, see the documentation of + the command-line flag.</p> </item> <tag><c>dirty_cpu_schedulers</c></tag> <item> - <marker id="system_info_dirty_cpu_schedulers"></marker> + <marker id="system_info_dirty_cpu_schedulers"></marker> <p>Returns the number of dirty CPU scheduler threads used by the emulator. Dirty CPU schedulers execute CPU-bound native functions, such as NIFs, linked-in driver code, @@ -7355,23 +7477,31 @@ ok can be changed at any time. The number of dirty CPU schedulers can be set at startup by passing command-line flag - <seealso marker="erts:erl#+SDcpu">+SDcpu</seealso> or - <seealso marker="erts:erl#+SDPcpu">+SDPcpu</seealso> in + <seealso marker="erts:erl#+SDcpu"><c>+SDcpu</c></seealso> or + <seealso marker="erts:erl#+SDPcpu"><c>+SDPcpu</c></seealso> in <c>erl(1)</c>.</p> - <p>Notice that the dirty schedulers functionality is + <p>Notice that the dirty schedulers functionality is experimental. Enable support for dirty schedulers when building OTP to try out the functionality.</p> <p>See also - <seealso marker="#system_flag_dirty_cpu_schedulers_online">erlang:system_flag(dirty_cpu_schedulers_online, DirtyCPUSchedulersOnline)</seealso>, - <seealso marker="#system_info_dirty_cpu_schedulers_online">erlang:system_info(dirty_cpu_schedulers_online)</seealso>, - <seealso marker="#system_info_dirty_io_schedulers">erlang:system_info(dirty_io_schedulers)</seealso>, - <seealso marker="#system_info_schedulers">erlang:system_info(schedulers)</seealso>, - <seealso marker="#system_info_schedulers_online">erlang:system_info(schedulers_online)</seealso>, and - <seealso marker="#system_flag_schedulers_online">erlang:system_flag(schedulers_online, SchedulersOnline)</seealso>.</p> + <seealso marker="#system_flag_dirty_cpu_schedulers_online"> + <c>erlang:system_flag(dirty_cpu_schedulers_online, + DirtyCPUSchedulersOnline)</c></seealso>, + <seealso marker="#system_info_dirty_cpu_schedulers_online"> + <c>erlang:system_info(dirty_cpu_schedulers_online)</c></seealso>, + <seealso marker="#system_info_dirty_io_schedulers"> + <c>erlang:system_info(dirty_io_schedulers)</c></seealso>, + <seealso marker="#system_info_schedulers"> + <c>erlang:system_info(schedulers)</c></seealso>, + <seealso marker="#system_info_schedulers_online"> + <c>erlang:system_info(schedulers_online)</c></seealso>, and + <seealso marker="#system_flag_schedulers_online"> + <c>erlang:system_flag(schedulers_online, + SchedulersOnline)</c></seealso>.</p> </item> <tag><c>dirty_cpu_schedulers_online</c></tag> <item> - <marker id="system_info_dirty_cpu_schedulers_online"></marker> + <marker id="system_info_dirty_cpu_schedulers_online"></marker> <p>Returns the number of dirty CPU schedulers online. The return value satisfies <c><![CDATA[1 <= DirtyCPUSchedulersOnline <= N]]></c>, @@ -7380,51 +7510,60 @@ ok <c>erlang:system_info(schedulers_online)</c>.</p> <p>The number of dirty CPU schedulers online can be set at startup by passing command-line flag - <seealso marker="erts:erl#+SDcpu">+SDcpu</seealso> in + <seealso marker="erts:erl#+SDcpu"><c>+SDcpu</c></seealso> in <c>erl(1)</c>.</p> <p>Notice that the dirty schedulers functionality is experimental. Enable support for dirty schedulers when building OTP to try out the functionality.</p> <p>For more information, see - <seealso marker="#system_info_dirty_cpu_schedulers">erlang:system_info(dirty_cpu_schedulers)</seealso>, - <seealso marker="#system_info_dirty_io_schedulers">erlang:system_info(dirty_io_schedulers)</seealso>, - <seealso marker="#system_info_schedulers_online">erlang:system_info(schedulers_online)</seealso>, and - <seealso marker="#system_flag_dirty_cpu_schedulers_online">erlang:system_flag(dirty_cpu_schedulers_online, DirtyCPUSchedulersOnline)</seealso>.</p> + <seealso marker="#system_info_dirty_cpu_schedulers"> + <c>erlang:system_info(dirty_cpu_schedulers)</c></seealso>, + <seealso marker="#system_info_dirty_io_schedulers"> + <c>erlang:system_info(dirty_io_schedulers)</c></seealso>, + <seealso marker="#system_info_schedulers_online"> + <c>erlang:system_info(schedulers_online)</c></seealso>, and + <seealso marker="#system_flag_dirty_cpu_schedulers_online"> + <c>erlang:system_flag(dirty_cpu_schedulers_online, + DirtyCPUSchedulersOnline)</c></seealso>.</p> </item> <tag><c>dirty_io_schedulers</c></tag> <item> - <marker id="system_info_dirty_io_schedulers"></marker> + <marker id="system_info_dirty_io_schedulers"></marker> <p>Returns the number of dirty I/O schedulers as an integer. Dirty I/O schedulers execute I/O-bound native functions, such as NIFs and linked-in driver code, which cannot be managed cleanly by the normal emulator schedulers.</p> <p>This value can be set at startup by passing command-line - argument <seealso marker="erts:erl#+SDio">+SDio</seealso> + argument <seealso marker="erts:erl#+SDio"><c>+SDio</c></seealso> in <c>erl(1)</c>.</p> - <p>Notice that the dirty schedulers functionality is + <p>Notice that the dirty schedulers functionality is experimental. Enable support for dirty schedulers when building OTP to try out the functionality.</p> <p>For more information, see - <seealso marker="#system_info_dirty_cpu_schedulers">erlang:system_info(dirty_cpu_schedulers)</seealso>, - <seealso marker="#system_info_dirty_cpu_schedulers_online">erlang:system_info(dirty_cpu_schedulers_online)</seealso>, and - <seealso marker="#system_flag_dirty_cpu_schedulers_online">erlang:system_flag(dirty_cpu_schedulers_online, DirtyCPUSchedulersOnline)</seealso>.</p> + <seealso marker="#system_info_dirty_cpu_schedulers"> + <c>erlang:system_info(dirty_cpu_schedulers)</c></seealso>, + <seealso marker="#system_info_dirty_cpu_schedulers_online"> + <c>erlang:system_info(dirty_cpu_schedulers_online)</c></seealso>, + and <seealso marker="#system_flag_dirty_cpu_schedulers_online"> + <c>erlang:system_flag(dirty_cpu_schedulers_online, + DirtyCPUSchedulersOnline)</c></seealso>.</p> </item> <tag><c>dist</c></tag> <item> <p>Returns a binary containing a string of distribution information formatted as in Erlang crash dumps. For more - information, see Section - <seealso marker="erts:crash_dump">"How to interpret the Erlang crash dumps"</seealso> + information, see section <seealso marker="erts:crash_dump"> + How to interpret the Erlang crash dumps</seealso> in the User's Guide.</p> </item> <tag><c>dist_buf_busy_limit</c></tag> <item> - <marker id="system_info_dist_buf_busy_limit"></marker> + <marker id="system_info_dist_buf_busy_limit"></marker> <p>Returns the value of the distribution buffer busy limit - in bytes. This limit can be set at startup by passing - command-line flag - <seealso marker="erts:erl#+zdbbl">+zdbbl</seealso> - to <c>erl</c>.</p> + in bytes. This limit can be set at startup by passing + command-line flag + <seealso marker="erts:erl#+zdbbl"><c>+zdbbl</c></seealso> + to <c>erl(1)</c>.</p> </item> <tag><c>dist_ctrl</c></tag> <item> @@ -7442,61 +7581,63 @@ ok <item> <p>Returns a string containing the Erlang driver version used by the runtime system. It has the form - <seealso marker="erts:erl_driver#version_management">"<major ver>.<minor ver>"</seealso>.</p> + <seealso marker="erts:erl_driver#version_management"> + "<major ver>.<minor ver>"</seealso>.</p> </item> <tag><c>dynamic_trace</c></tag> <item> <p>Returns an atom describing the dynamic trace framework - compiled into the virtual machine. It can be - <c>dtrace</c>, <c>systemtap</c>, or <c>none</c>. For a - commercial or standard build, it is always <c>none</c>. - The other return values indicate a custom configuration - (for example, <c>./configure --with-dynamic-trace=dtrace</c>). - For more information about dynamic tracing, see the - <seealso marker="runtime_tools:dyntrace">dyntrace</seealso> - manual page and the - <c>README.dtrace</c>/<c>README.systemtap</c> files in the - Erlang source code top directory.</p> + compiled into the virtual machine. It can be + <c>dtrace</c>, <c>systemtap</c>, or <c>none</c>. For a + commercial or standard build, it is always <c>none</c>. + The other return values indicate a custom configuration + (for example, <c>./configure --with-dynamic-trace=dtrace</c>). + For more information about dynamic tracing, see + <seealso marker="runtime_tools:dyntrace"> + <c>runtime_tools:dyntrace(3)</c></seealso> manual page and the + <c>README.dtrace</c>/<c>README.systemtap</c> files in the + Erlang source code top directory.</p> </item> <tag><c>dynamic_trace_probes</c></tag> <item> <p>Returns a <c>boolean()</c> indicating if dynamic trace - probes (<c>dtrace</c> or <c>systemtap</c>) are built into - the emulator. This can only be <c>true</c> if the Virtual - Machine was built for dynamic tracing (that is, - <c>system_info(dynamic_trace)</c> returns - <c>dtrace</c> or <c>systemtap</c>).</p> - </item> - <tag><marker id="system_info_end_time"/><c>end_time</c></tag> - <item><p>The last <seealso marker="#monotonic_time/0">Erlang monotonic - time</seealso> in <c>native</c> - <seealso marker="#type_time_unit">time unit</seealso> that - can be represented internally in the current Erlang runtime system - instance. The time between the - <seealso marker="#system_info_start_time">start time</seealso> and - the end time is at least a quarter of a millennium.</p></item> + probes (<c>dtrace</c> or <c>systemtap</c>) are built into + the emulator. This can only be <c>true</c> if the virtual + machine was built for dynamic tracing (that is, + <c>system_info(dynamic_trace)</c> returns + <c>dtrace</c> or <c>systemtap</c>).</p> + </item> + <tag><marker id="system_info_end_time"/><c>end_time</c></tag> + <item> + <p>The last <seealso marker="#monotonic_time/0">Erlang monotonic + time</seealso> in <c>native</c> + <seealso marker="#type_time_unit">time unit</seealso> that + can be represented internally in the current Erlang runtime system + instance. The time between the + <seealso marker="#system_info_start_time">start time</seealso> and + the end time is at least a quarter of a millennium.</p> + </item> <tag><c>elib_malloc</c></tag> <item> <p>This option will be removed in a future release. - The return value will always be <c>false</c>, as the - <c>elib_malloc</c> allocator has been removed.</p> + The return value will always be <c>false</c>, as the + <c>elib_malloc</c> allocator has been removed.</p> </item> - <tag><marker id="system_info_eager_check_io"/><c>eager_check_io</c></tag> + <tag><marker id="system_info_eager_check_io"/> + <c>eager_check_io</c></tag> <item> - <p> - Returns the value of the <c>erl</c> command line flag - <seealso marker="erl#+secio">+secio</seealso> - which is either <c>true</c> or <c>false</c>. See the - documentation of the command line flag for information about - the different values. - </p> + <p>Returns the value of command-line flag + <seealso marker="erl#+secio"><c>+secio</c></seealso> in + <c>erl(1)</c>, which is either <c>true</c> or <c>false</c>. + For information about the different values, see the + documentation of the command-line flag.</p> </item> <tag><c>ets_limit</c></tag> <item> - <p>Returns the maximum number of ETS tables allowed. This + <p>Returns the maximum number of <c>ets</c> tables allowed. This limit can be increased at startup by passing command-line flag - <seealso marker="erts:erl#+e">+e</seealso> to + <seealso marker="erts:erl#+e"><c>+e</c></seealso> to <c>erl(1)</c> or by setting environment variable <c>ERL_MAX_ETS_TABLES</c> before starting the Erlang runtime system.</p> @@ -7514,10 +7655,10 @@ ok <taglist> <tag><c>private</c></tag> <item> - <p>Each process has a heap reserved for its use and no - references between heaps of different processes are - allowed. Messages passed between processes are copied - between heaps.</p> + Each process has a heap reserved for its use and no + references between heaps of different processes are + allowed. Messages passed between processes are copied + between heaps. </item> </taglist> </item> @@ -7525,8 +7666,9 @@ ok <item> <p>Returns a binary containing a string of miscellaneous system information formatted as in Erlang crash dumps. - For more information, see Section - <seealso marker="erts:crash_dump">"How to interpret the Erlang crash dumps"</seealso> + For more information, see section + <seealso marker="erts:crash_dump"> + How to interpret the Erlang crash dumps</seealso> in the User's Guide.</p> </item> <tag><c>kernel_poll</c></tag> @@ -7538,38 +7680,39 @@ ok <item> <p>Returns a binary containing a string of loaded module information formatted as in Erlang crash dumps. For more - information, see Section - <seealso marker="erts:crash_dump">"How to interpret the Erlang crash dumps"</seealso> - in the User's Guide.</p> + information, see section + <seealso marker="erts:crash_dump">How to interpret the Erlang + crash dumps</seealso> in the User's Guide.</p> </item> - <tag><c>logical_processors</c></tag> + <tag><c>logical_processors</c></tag> <item> - <marker id="logical_processors"></marker> + <marker id="logical_processors"></marker> <p>Returns the detected number of logical processors configured - in the system. The return value is either an integer, or - the atom <c>unknown</c> if the emulator cannot - detect the configured logical processors.</p> + in the system. The return value is either an integer, or + the atom <c>unknown</c> if the emulator cannot + detect the configured logical processors.</p> </item> - <tag><c>logical_processors_available</c></tag> + <tag><c>logical_processors_available</c></tag> <item> - <marker id="logical_processors_available"></marker> + <marker id="logical_processors_available"></marker> <p>Returns the detected number of logical processors available - to the Erlang runtime system. The return value is either an - integer, or the atom <c>unknown</c> if the emulator - cannot detect the available logical processors. The number - of available logical processors is less than or equal to - the number of - <seealso marker="#logical_processors_online">logical processors online</seealso>.</p> + to the Erlang runtime system. The return value is either an + integer, or the atom <c>unknown</c> if the emulator + cannot detect the available logical processors. The number + of available logical processors is less than or equal to + the number of <seealso marker="#logical_processors_online"> + logical processors online</seealso>.</p> </item> - <tag><c>logical_processors_online</c></tag> + <tag><c>logical_processors_online</c></tag> <item> - <marker id="logical_processors_online"></marker> + <marker id="logical_processors_online"></marker> <p>Returns the detected number of logical processors online on - the system. The return value is either an integer, - or the atom <c>unknown</c> if the emulator cannot - detect logical processors online. The number of logical - processors online is less than or equal to the number of - <seealso marker="#logical_processors">logical processors configured</seealso>.</p> + the system. The return value is either an integer, + or the atom <c>unknown</c> if the emulator cannot + detect logical processors online. The number of logical + processors online is less than or equal to the number of + <seealso marker="#logical_processors">logical processors + configured</seealso>.</p> </item> <tag><c>machine</c></tag> <item> @@ -7578,17 +7721,16 @@ ok <tag><c>modified_timing_level</c></tag> <item> <p>Returns the modified timing-level (an integer) if - modified timing is enabled, otherwise, <c>undefined</c>. + modified timing is enabled, otherwise <c>undefined</c>. For more information about modified timing, see command-line flag - <seealso marker="erts:erl#+T">+T</seealso> + <seealso marker="erts:erl#+T"><c>+T</c></seealso> in <c>erl(1)</c></p> </item> <tag><c>multi_scheduling</c></tag> <item> - <marker id="system_info_multi_scheduling"></marker> - <p>Returns <c>disabled</c>, <c>blocked</c>, <c>blocked_normal</c>, - or <c>enabled</c>:</p> + <marker id="system_info_multi_scheduling"></marker> + <p>Returns one of the following:</p> <taglist> <tag><c>disabled</c></tag> <item> @@ -7607,9 +7749,9 @@ ok <item> <p>The emulator has more than one scheduler thread, but all normal scheduler threads except one are - blocked. Note that dirty schedulers are not - blocked, and may schedule Erlang processes and - execute native code.</p> + blocked. Notice that dirty schedulers are not + blocked, and can schedule Erlang processes and + execute native code.</p> </item> <tag><c>enabled</c></tag> <item> @@ -7620,189 +7762,204 @@ ok </item> </taglist> <p>See also - <seealso marker="#system_flag_multi_scheduling">erlang:system_flag(multi_scheduling, BlockState)</seealso>, - <seealso marker="#system_info_multi_scheduling_blockers">erlang:system_info(multi_scheduling_blockers)</seealso>, - <seealso marker="#system_info_normal_multi_scheduling_blockers">erlang:system_info(normal_multi_scheduling_blockers)</seealso>, - and - <seealso marker="#system_info_schedulers">erlang:system_info(schedulers)</seealso>.</p> + <seealso marker="#system_flag_multi_scheduling"> + <c>erlang:system_flag(multi_scheduling, BlockState)</c></seealso>, + <seealso marker="#system_info_multi_scheduling_blockers"> + <c>erlang:system_info(multi_scheduling_blockers)</c></seealso>, + <seealso marker="#system_info_normal_multi_scheduling_blockers"> + <c>erlang:system_info(normal_multi_scheduling_blockers)</c></seealso>, + and <seealso marker="#system_info_schedulers"> + <c>erlang:system_info(schedulers)</c></seealso>.</p> </item> <tag><c>multi_scheduling_blockers</c></tag> <item> - <marker id="system_info_multi_scheduling_blockers"></marker> + <marker id="system_info_multi_scheduling_blockers"></marker> <p>Returns a list of <c><anno>Pid</anno></c>s when multi-scheduling is blocked, otherwise the empty list is returned. The <c><anno>Pid</anno></c>s in the list - represent all the processes currently + represent all the processes currently blocking multi-scheduling. A <c><anno>Pid</anno></c> occurs only once in the list, even if the corresponding process has blocked multiple times.</p> <p>See also - <seealso marker="#system_flag_multi_scheduling">erlang:system_flag(multi_scheduling, BlockState)</seealso>, - <seealso marker="#system_info_multi_scheduling">erlang:system_info(multi_scheduling)</seealso>, - <seealso marker="#system_info_normal_multi_scheduling_blockers">erlang:system_info(normal_multi_scheduling_blockers)</seealso>, - - and - <seealso marker="#system_info_schedulers">erlang:system_info(schedulers)</seealso>.</p> + <seealso marker="#system_flag_multi_scheduling"> + <c>erlang:system_flag(multi_scheduling, BlockState)</c></seealso>, + <seealso marker="#system_info_multi_scheduling"> + <c>erlang:system_info(multi_scheduling)</c></seealso>, + <seealso marker="#system_info_normal_multi_scheduling_blockers"> + <c>erlang:system_info(normal_multi_scheduling_blockers)</c></seealso>, + and <seealso marker="#system_info_schedulers"> + <c>erlang:system_info(schedulers)</c></seealso>.</p> </item> <tag><c>nif_version</c></tag> <item> - <p>Returns a string containing the version of the Erlang NIF interface - used by the runtime system. It is on the form - "<major ver>.<minor ver>".</p> + <p>Returns a string containing the version of the Erlang NIF + interface used by the runtime system. It is on the form + "<major ver>.<minor ver>".</p> </item> <tag><c>normal_multi_scheduling_blockers</c></tag> <item> - <marker id="system_info_normal_multi_scheduling_blockers"></marker> + <marker id="system_info_normal_multi_scheduling_blockers"></marker> <p>Returns a list of <c><anno>Pid</anno></c>s when - normal multi-scheduling is blocked (i.e. all normal schedulers - but one is blocked), otherwise the empty list is returned. - The <c><anno>Pid</anno></c>s in the list represent all the - processes currently blocking normal multi-scheduling. - A <c><anno>Pid</anno></c> occurs only once in the list, even if - the corresponding process has blocked multiple times.</p> + normal multi-scheduling is blocked (that is, all normal schedulers + but one is blocked), otherwise the empty list is returned. + The <c><anno>Pid</anno></c>s in the list represent all the + processes currently blocking normal multi-scheduling. + A <c><anno>Pid</anno></c> occurs only once in the list, even if + the corresponding process has blocked multiple times.</p> <p>See also - <seealso marker="#system_flag_multi_scheduling">erlang:system_flag(multi_scheduling, BlockState)</seealso>, - <seealso marker="#system_info_multi_scheduling">erlang:system_info(multi_scheduling)</seealso>, - <seealso marker="#system_info_multi_scheduling_blockers">erlang:system_info(multi_scheduling_blockers)</seealso>, - - and - <seealso marker="#system_info_schedulers">erlang:system_info(schedulers)</seealso>.</p> - </item> - <tag><marker id="system_info_otp_release"/><c>otp_release</c></tag> - <item> - <marker id="system_info_otp_release"></marker> + <seealso marker="#system_flag_multi_scheduling"> + <c>erlang:system_flag(multi_scheduling, BlockState)</c></seealso>, + <seealso marker="#system_info_multi_scheduling"> + <c>erlang:system_info(multi_scheduling)</c></seealso>, + <seealso marker="#system_info_multi_scheduling_blockers"> + <c>erlang:system_info(multi_scheduling_blockers)</c></seealso>, + and <seealso marker="#system_info_schedulers"> + <c>erlang:system_info(schedulers)</c></seealso>.</p> + </item> + <tag><marker id="system_info_otp_release"/> + <c>otp_release</c></tag> + <item> + <marker id="system_info_otp_release"></marker> <p>Returns a string containing the OTP release number of the - OTP release that the currently executing <c>ERTS</c> application is - part of.</p> - <p>As from OTP 17, the OTP release number corresponds to - the major OTP version number. No - <c>erlang:system_info()</c> argument gives the exact OTP - version. This is because the exact OTP version in the general case - is difficult to determine. For more information, see the description - of versions in <seealso marker="doc/system_principles:versions"> - System principles</seealso> in System Documentation.</p> - </item> - <tag><marker id="system_info_os_monotonic_time_source"/><c>os_monotonic_time_source</c></tag> + OTP release that the currently executing <c>ERTS</c> application + is part of.</p> + <p>As from Erlang/OTP 17, the OTP release number corresponds to + the major OTP version number. No + <c>erlang:system_info()</c> argument gives the exact OTP + version. This is because the exact OTP version in the general case + is difficult to determine. For more information, see the + description of versions in + <seealso marker="doc/system_principles:versions"> + System principles</seealso> in System Documentation.</p> + </item> + <tag><marker id="system_info_os_monotonic_time_source"/> + <c>os_monotonic_time_source</c></tag> <item> <p>Returns a list containing information about the source of - <seealso marker="erts:time_correction#OS_Monotonic_Time">OS - monotonic time</seealso> that is used by the runtime system.</p> - <p>If <c>[]</c> is returned, no OS monotonic time is - available. The list contains two-tuples with <c>Key</c>s - as first element, and <c>Value</c>s as second element. The - order of these tuples is undefined. The following - tuples can be part of the list, but more tuples can be - introduced in the future:</p> - <taglist> - <tag><c>{function, Function}</c></tag> - <item><p><c>Function</c> is the name of the function - used. This tuple always exist if OS monotonic time is - available to the runtime system.</p></item> - - <tag><c>{clock_id, ClockId}</c></tag> - <item><p>This tuple only exist if <c>Function</c> - can be used with different clocks. <c>ClockId</c> - corresponds to the clock identifier used when calling - <c>Function</c>.</p></item> - - <tag><c>{resolution, OsMonotonicTimeResolution}</c></tag> - <item><p>Highest possible - <seealso marker="time_correction#Time_Resolution">resolution</seealso> - of current OS monotonic time source as parts per - second. If no resolution information can be retrieved - from the OS, <c>OsMonotonicTimeResolution</c> is - set to the resolution of the time unit of - <c>Function</c>s return value. That is, the actual - resolution can be lower than - <c>OsMonotonicTimeResolution</c>. Also note that - the resolution does not say anything about the - <seealso marker="time_correction#Time_Accuracy">accuracy</seealso>, - and whether the - <seealso marker="time_correction#Time_Precision">precision</seealso> - do align with the resolution. You do, - however, know that the precision is not better than - <c>OsMonotonicTimeResolution</c>.</p></item> - - <tag><c>{extended, Extended}</c></tag> - <item><p><c>Extended</c> equals <c>yes</c> if - the range of time values has been extended; - otherwise, <c>Extended</c> equals <c>no</c>. The - range needs to be extended if <c>Function</c> - returns values that wrap fast. This typically - is the case when the return value is a 32-bit - value.</p></item> - - <tag><c>{parallel, Parallel}</c></tag> - <item><p><c>Parallel</c> equals <c>yes</c> if - <c>Function</c> is called in parallel from multiple - threads. If it is not called in parallel, because - calls needs to be serialized, <c>Parallel</c> equals - <c>no</c>.</p></item> - - <tag><c>{time, OsMonotonicTime}</c></tag> - <item><p><c>OsMonotonicTime</c> equals current OS - monotonic time in <c>native</c> - <seealso marker="#type_time_unit">time unit</seealso>.</p></item> - </taglist> - </item> - <tag><marker id="system_info_os_system_time_source"/><c>os_system_time_source</c></tag> + <seealso marker="erts:time_correction#OS_Monotonic_Time">OS + monotonic time</seealso> that is used by the runtime system.</p> + <p>If <c>[]</c> is returned, no OS monotonic time is + available. The list contains two-tuples with <c>Key</c>s + as first element, and <c>Value</c>s as second element. The + order of these tuples is undefined. The following + tuples can be part of the list, but more tuples can be + introduced in the future:</p> + <taglist> + <tag><c>{function, Function}</c></tag> + <item><p><c>Function</c> is the name of the function + used. This tuple always exists if OS monotonic time is + available to the runtime system.</p> + </item> + <tag><c>{clock_id, ClockId}</c></tag> + <item><p>This tuple only exists if <c>Function</c> + can be used with different clocks. <c>ClockId</c> + corresponds to the clock identifier used when calling + <c>Function</c>.</p> + </item> + <tag><c>{resolution, OsMonotonicTimeResolution}</c></tag> + <item><p>Highest possible + <seealso marker="time_correction#Time_Resolution"> + resolution</seealso> + of current OS monotonic time source as parts per + second. If no resolution information can be retrieved + from the OS, <c>OsMonotonicTimeResolution</c> is + set to the resolution of the time unit of + <c>Function</c>s return value. That is, the actual + resolution can be lower than + <c>OsMonotonicTimeResolution</c>. Notice that + the resolution does not say anything about the + <seealso marker="time_correction#Time_Accuracy"> + accuracy</seealso> or whether the + <seealso marker="time_correction#Time_Precision"> + precision</seealso> aligns with the resolution. You do, + however, know that the precision is not better than + <c>OsMonotonicTimeResolution</c>.</p> + </item> + <tag><c>{extended, Extended}</c></tag> + <item><p><c>Extended</c> equals <c>yes</c> if + the range of time values has been extended; + otherwise <c>Extended</c> equals <c>no</c>. The + range must be extended if <c>Function</c> + returns values that wrap fast. This typically + is the case when the return value is a 32-bit value.</p> + </item> + <tag><c>{parallel, Parallel}</c></tag> + <item><p><c>Parallel</c> equals <c>yes</c> if + <c>Function</c> is called in parallel from multiple + threads. If it is not called in parallel, because + calls must be serialized, <c>Parallel</c> equals + <c>no</c>.</p> + </item> + <tag><c>{time, OsMonotonicTime}</c></tag> + <item><p><c>OsMonotonicTime</c> equals current OS + monotonic time in <c>native</c> + <seealso marker="#type_time_unit">time unit</seealso>.</p> + </item> + </taglist> + </item> + <tag><marker id="system_info_os_system_time_source"/> + <c>os_system_time_source</c></tag> <item> <p>Returns a list containing information about the source of - <seealso marker="erts:time_correction#OS_System_Time">OS - system time</seealso> that is used by the runtime system.</p> - <p>The list contains two-tuples with <c>Key</c>s - as first element, and <c>Value</c>s as second element. The - order if these tuples is undefined. The following - tuples can be part of the list, but more tuples can be - introduced in the future:</p> - <taglist> - <tag><c>{function, Function}</c></tag> - <item><p><c>Function</c> is the name of the funcion - used.</p></item> - - <tag><c>{clock_id, ClockId}</c></tag> - <item><p>This tuple only exist if <c>Function</c> - can be used with different clocks. <c>ClockId</c> - corresponds to the clock identifier used when calling - <c>Function</c>.</p></item> - - <tag><c>{resolution, OsSystemTimeResolution}</c></tag> - <item><p>Highest possible - <seealso marker="time_correction#Time_Resolution">resolution</seealso> - of current OS system time source as parts per - second. If no resolution information can be retrieved - from the OS, <c>OsSystemTimeResolution</c> is - set to the resolution of the time unit of - <c>Function</c>s return value. That is, the actual - resolution may be lower than - <c>OsSystemTimeResolution</c>. Also note that - the resolution does not say anything about the - <seealso marker="time_correction#Time_Accuracy">accuracy</seealso>, - and whether the - <seealso marker="time_correction#Time_Precision">precision</seealso> - do align with the resolution. You do, - however, know that the precision is not better than - <c>OsSystemTimeResolution</c>.</p></item> - - <tag><c>{parallel, Parallel}</c></tag> - <item><p><c>Parallel</c> equals <c>yes</c> if - <c>Function</c> is called in parallel from multiple - threads. If it is not called in parallel, because - calls needs to be serialized, <c>Parallel</c> equals - <c>no</c>.</p></item> - - <tag><c>{time, OsSystemTime}</c></tag> - <item><p><c>OsSystemTime</c> equals current OS - system time in <c>native</c> - <seealso marker="#type_time_unit">time unit</seealso>.</p></item> - </taglist> - </item> - <tag><c>port_parallelism</c></tag> - <item> - <marker id="system_info_port_parallelism"></marker> - <p>Returns the default port parallelism scheduling hint used. - For more information, see command-line argument - <seealso marker="erl#+spp">+spp</seealso> in <c>erl(1)</c>.</p></item> + <seealso marker="erts:time_correction#OS_System_Time">OS + system time</seealso> that is used by the runtime system.</p> + <p>The list contains two-tuples with <c>Key</c>s + as first element, and <c>Value</c>s as second element. The + order if these tuples is undefined. The following + tuples can be part of the list, but more tuples can be + introduced in the future:</p> + <taglist> + <tag><c>{function, Function}</c></tag> + <item><p><c>Function</c> is the name of the funcion used.</p> + </item> + <tag><c>{clock_id, ClockId}</c></tag> + <item><p>Exists only if <c>Function</c> + can be used with different clocks. <c>ClockId</c> + corresponds to the clock identifier used when calling + <c>Function</c>.</p> + </item> + <tag><c>{resolution, OsSystemTimeResolution}</c></tag> + <item><p>Highest possible + <seealso marker="time_correction#Time_Resolution"> + resolution</seealso> + of current OS system time source as parts per + second. If no resolution information can be retrieved + from the OS, <c>OsSystemTimeResolution</c> is + set to the resolution of the time unit of + <c>Function</c>s return value. That is, the actual + resolution can be lower than + <c>OsSystemTimeResolution</c>. Notice that + the resolution does not say anything about the + <seealso marker="time_correction#Time_Accuracy"> + accuracy</seealso> or whether the + <seealso marker="time_correction#Time_Precision"> + precision</seealso> do align with the resolution. You do, + however, know that the precision is not better than + <c>OsSystemTimeResolution</c>.</p> + </item> + <tag><c>{parallel, Parallel}</c></tag> + <item><p><c>Parallel</c> equals <c>yes</c> if + <c>Function</c> is called in parallel from multiple + threads. If it is not called in parallel, because + calls needs to be serialized, <c>Parallel</c> equals + <c>no</c>.</p> + </item> + <tag><c>{time, OsSystemTime}</c></tag> + <item><p><c>OsSystemTime</c> equals current OS + system time in <c>native</c> + <seealso marker="#type_time_unit">time unit</seealso>.</p> + </item> + </taglist> + </item> + <tag><c>port_parallelism</c></tag> + <item> + <marker id="system_info_port_parallelism"></marker> + <p>Returns the default port parallelism scheduling hint used. + For more information, see command-line argument + <seealso marker="erl#+spp"><c>+spp</c></seealso> + in <c>erl(1)</c>.</p> + </item> <tag><marker id="system_info_port_count"/><c>port_count</c></tag> <item> <p>Returns the number of ports currently existing at the @@ -7816,9 +7973,10 @@ ok <p>Returns the maximum number of simultaneously existing ports at the local node as an integer. This limit can be configured at startup by using command-line flag - <seealso marker="erl#+Q">+Q</seealso> in <c>erl(1)</c>.</p> + <seealso marker="erl#+Q"><c>+Q</c></seealso> in <c>erl(1)</c>.</p> </item> - <tag><marker id="system_info_process_count"/><c>process_count</c></tag> + <tag><marker id="system_info_process_count"/> + <c>process_count</c></tag> <item> <p>Returns the number of processes currently existing at the local node. The value is given as an integer. This is @@ -7827,74 +7985,78 @@ ok </item> <tag><c>process_limit</c></tag> <item> - <marker id="system_info_process_limit"></marker> + <marker id="system_info_process_limit"></marker> <p>Returns the maximum number of simultaneously existing processes at the local node. The value is given as an integer. This limit can be configured at startup by using - command-line flag <seealso marker="erl#+P">+P</seealso> - in <c>erl(1)</c>.</p> + command-line flag <seealso marker="erl#+P"><c>+P</c></seealso> + in <c>erl(1)</c>.</p> </item> <tag><c>procs</c></tag> <item> <p>Returns a binary containing a string of process and port information formatted as in Erlang crash dumps. For more - information, see Section - <seealso marker="erts:crash_dump">"How to interpret the Erlang crash dumps"</seealso> + information, see section <seealso marker="erts:crash_dump"> + How to interpret the Erlang crash dumps</seealso> in the User's Guide.</p> </item> <tag><c>scheduler_bind_type</c></tag> <item> - <marker id="system_info_scheduler_bind_type"></marker> - <p>Returns information about how the user has requested - schedulers to be bound or not bound.</p> - <p>Notice that even though a user has requested - schedulers to be bound, they can silently have failed - to bind. To inspect the scheduler bindings, call - <seealso marker="#system_info_scheduler_bindings">erlang:system_info(scheduler_bindings)</seealso>.</p> - <p>For more information, see command-line argument - <seealso marker="erts:erl#+sbt">+sbt</seealso> - in <c>erl(1)</c> and - <seealso marker="#system_info_scheduler_bindings">erlang:system_info(scheduler_bindings)</seealso>.</p> + <marker id="system_info_scheduler_bind_type"></marker> + <p>Returns information about how the user has requested + schedulers to be bound or not bound.</p> + <p>Notice that although a user has requested + schedulers to be bound, they can silently have failed + to bind. To inspect the scheduler bindings, call + <seealso marker="#system_info_scheduler_bindings"> + <c>erlang:system_info(scheduler_bindings)</c></seealso>.</p> + <p>For more information, see command-line argument + <seealso marker="erts:erl#+sbt"><c>+sbt</c></seealso> + in <c>erl(1)</c> and + <seealso marker="#system_info_scheduler_bindings"> + <c>erlang:system_info(scheduler_bindings)</c></seealso>.</p> </item> <tag><c>scheduler_bindings</c></tag> <item> - <marker id="system_info_scheduler_bindings"></marker> - <p>Returns information about the currently used scheduler - bindings.</p> - <p>A tuple of a size equal to - <seealso marker="#system_info_schedulers">erlang:system_info(schedulers)</seealso> - is returned. The tuple elements are integers - or the atom <c>unbound</c>. Logical processor identifiers - are represented as integers. The <c>N</c>th - element of the tuple equals the current binding for - the scheduler with the scheduler identifier equal to - <c>N</c>. For example, if the schedulers are bound, - <c>element(erlang:system_info(scheduler_id), - erlang:system_info(scheduler_bindings))</c> returns - the identifier of the logical processor that the calling - process is executing on.</p> - <p>Notice that only schedulers online can be bound to logical - processors.</p> - <p>For more information, see command-line argument - <seealso marker="erts:erl#+sbt">+sbt</seealso> - in <c>erl(1)</c> and - <seealso marker="#system_info_schedulers_online">erlang:system_info(schedulers_online)</seealso>. - </p> + <marker id="system_info_scheduler_bindings"></marker> + <p>Returns information about the currently used scheduler + bindings.</p> + <p>A tuple of a size equal to + <seealso marker="#system_info_schedulers"> + <c>erlang:system_info(schedulers)</c></seealso> + is returned. The tuple elements are integers + or the atom <c>unbound</c>. Logical processor identifiers + are represented as integers. The <c>N</c>th + element of the tuple equals the current binding for + the scheduler with the scheduler identifier equal to + <c>N</c>. For example, if the schedulers are bound, + <c>element(erlang:system_info(scheduler_id), + erlang:system_info(scheduler_bindings))</c> returns + the identifier of the logical processor that the calling + process is executing on.</p> + <p>Notice that only schedulers online can be bound to logical + processors.</p> + <p>For more information, see command-line argument + <seealso marker="erts:erl#+sbt"><c>+sbt</c></seealso> + in <c>erl(1)</c> and + <seealso marker="#system_info_schedulers_online"> + <c>erlang:system_info(schedulers_online)</c></seealso>.</p> </item> <tag><c>scheduler_id</c></tag> <item> - <marker id="system_info_scheduler_id"></marker> + <marker id="system_info_scheduler_id"></marker> <p>Returns the scheduler ID (<c>SchedulerId</c>) of the scheduler thread that the calling process is executing on. <c><anno>SchedulerId</anno></c> is a positive integer, - where - <c><![CDATA[1 <= SchedulerId <= erlang:system_info(schedulers)]]></c>. - See also - <seealso marker="#system_info_schedulers">erlang:system_info(schedulers)</seealso>.</p> + where <c><![CDATA[1 <= SchedulerId <= + erlang:system_info(schedulers)]]></c>.</p> + <p>See also + <seealso marker="#system_info_schedulers"> + <c>erlang:system_info(schedulers)</c></seealso>.</p> </item> <tag><c>schedulers</c></tag> <item> - <marker id="system_info_schedulers"></marker> + <marker id="system_info_schedulers"></marker> <p>Returns the number of scheduler threads used by the emulator. Scheduler threads online schedules Erlang processes and Erlang ports, and execute Erlang code @@ -7902,44 +8064,57 @@ ok <p>The number of scheduler threads is determined at emulator boot time and cannot be changed later. However, the number of schedulers online can - be changed at any time.</p> + be changed at any time.</p> <p>See also - <seealso marker="#system_flag_schedulers_online">erlang:system_flag(schedulers_online, SchedulersOnline)</seealso>, - <seealso marker="#system_info_schedulers_online">erlang:system_info(schedulers_online)</seealso>, - <seealso marker="#system_info_scheduler_id">erlang:system_info(scheduler_id)</seealso>, - <seealso marker="#system_flag_multi_scheduling">erlang:system_flag(multi_scheduling, BlockState)</seealso>, - <seealso marker="#system_info_multi_scheduling">erlang:system_info(multi_scheduling)</seealso>, - <seealso marker="#system_info_normal_multi_scheduling_blockers">erlang:system_info(normal_multi_scheduling_blockers)</seealso> - and - <seealso marker="#system_info_multi_scheduling_blockers">erlang:system_info(multi_scheduling_blockers)</seealso>.</p> + <seealso marker="#system_flag_schedulers_online"> + <c>erlang:system_flag(schedulers_online, + SchedulersOnline)</c></seealso>, + <seealso marker="#system_info_schedulers_online"> + <c>erlang:system_info(schedulers_online)</c></seealso>, + <seealso marker="#system_info_scheduler_id"> + <c>erlang:system_info(scheduler_id)</c></seealso>, + <seealso marker="#system_flag_multi_scheduling"> + <c>erlang:system_flag(multi_scheduling, BlockState)</c></seealso>, + <seealso marker="#system_info_multi_scheduling"> + <c>erlang:system_info(multi_scheduling)</c></seealso>, + <seealso marker="#system_info_normal_multi_scheduling_blockers"> + <c>erlang:system_info(normal_multi_scheduling_blockers)</c></seealso> + and <seealso marker="#system_info_multi_scheduling_blockers"> + <c>erlang:system_info(multi_scheduling_blockers)</c></seealso>. + </p> </item> <tag><c>schedulers_online</c></tag> <item> - <marker id="system_info_schedulers_online"></marker> + <marker id="system_info_schedulers_online"></marker> <p>Returns the number of schedulers online. The scheduler - identifiers of schedulers online satisfy the relationship - <c><![CDATA[1 <= SchedulerId <= erlang:system_info(schedulers_online)]]></c>.</p> - <p>For more information, see - <seealso marker="#system_info_schedulers">erlang:system_info(schedulers)</seealso> - and - <seealso marker="#system_flag_schedulers_online">erlang:system_flag(schedulers_online, SchedulersOnline)</seealso>.</p> + identifiers of schedulers online satisfy the relationship + <c><![CDATA[1 <= SchedulerId <= + erlang:system_info(schedulers_online)]]></c>.</p> + <p>For more information, see + <seealso marker="#system_info_schedulers"> + <c>erlang:system_info(schedulers)</c></seealso> and + <seealso marker="#system_flag_schedulers_online"> + <c>erlang:system_flag(schedulers_online, + SchedulersOnline)</c></seealso>.</p> </item> <tag><c>smp_support</c></tag> <item> <p>Returns <c>true</c> if the emulator has been compiled with SMP support, otherwise <c>false</c> is returned.</p> </item> - <tag><marker id="system_info_start_time"/><c>start_time</c></tag> - <item><p>The <seealso marker="#monotonic_time/0">Erlang monotonic - time</seealso> in <c>native</c> - <seealso marker="#type_time_unit">time unit</seealso> at the - time when current Erlang runtime system instance started. See also - <seealso marker="#system_info_end_time"><c>erlang:system_info(end_time)</c></seealso>. - </p></item> + <tag><marker id="system_info_start_time"/><c>start_time</c></tag> + <item> + <p>The <seealso marker="#monotonic_time/0">Erlang monotonic + time</seealso> in <c>native</c> + <seealso marker="#type_time_unit">time unit</seealso> at the + time when current Erlang runtime system instance started.</p> + <p>See also <seealso marker="#system_info_end_time"> + <c>erlang:system_info(end_time)</c></seealso>.</p> + </item> <tag><c>system_version</c></tag> <item> <p>Returns a string containing version number and - some important properties, such as the number of schedulers.</p> + some important properties, such as the number of schedulers.</p> </item> <tag><c>system_architecture</c></tag> <item> @@ -7953,105 +8128,114 @@ ok </item> <tag><c>thread_pool_size</c></tag> <item> - <marker id="system_info_thread_pool_size"></marker> + <marker id="system_info_thread_pool_size"></marker> <p>Returns the number of async threads in the async thread pool used for asynchronous driver calls - (<seealso marker="erts:erl_driver#driver_async">driver_async()</seealso>). + (<seealso marker="erts:erl_driver#driver_async"> + <c>erl_driver:driver_async()</c></seealso>). The value is given as an integer.</p> </item> - - <tag><c>time_correction</c></tag> - <item> - <marker id="system_info_time_correction"></marker> - <p>Returns a boolean value indicating whether - <seealso marker="time_correction#Time_Correction">time correction</seealso> - is enabled or not. - </p></item> - <tag><c>time_offset</c></tag> - <item> - <marker id="system_info_time_offset"></marker> - <p>Returns the state of the time offset:</p> - <taglist> - <tag><c>preliminary</c></tag> - <item><p>The time offset is preliminary, and will be changed - at a later time when being finalized. The preliminary time offset - is used during the preliminary phase of the - <seealso marker="time_correction#Single_Time_Warp_Mode">single - time warp mode</seealso>.</p></item> - - <tag><c>final</c></tag> - <item><p>The time offset is final. This either because - <seealso marker="time_correction#No_Time_Warp_Mode">no - time warp mode</seealso> is used, or because the time - offset have been finalized when - <seealso marker="time_correction#Single_Time_Warp_Mode">single - time warp mode</seealso> is used.</p></item> - - <tag><c>volatile</c></tag> - <item><p>The time offset is volatile. That is, it can - change at any time. This is because - <seealso marker="time_correction#Multi_Time_Warp_Mode">multi - time warp mode</seealso> is used.</p></item> - </taglist> - </item> - <tag><marker id="system_info_time_warp_mode"/><c>time_warp_mode</c></tag> - <item><p>Returns a value identifying the - <seealso marker="time_correction#Time_Warp_Modes">time warp - mode</seealso> being used:</p> - <taglist> - <tag><c>no_time_warp</c></tag> - <item><p>The <seealso marker="time_correction#No_Time_Warp_Mode">no - time warp mode</seealso> is used.</p></item> - - <tag><c>single_time_warp</c></tag> - <item><p>The <seealso marker="time_correction#Single_Time_Warp_Mode">single - time warp mode</seealso> is used.</p></item> - - <tag><c>multi_time_warp</c></tag> - <item><p>The <seealso marker="time_correction#Multi_Time_Warp_Mode">multi - time warp mode</seealso> is used.</p></item> - </taglist> - </item> + <tag><c>time_correction</c></tag> + <item> + <marker id="system_info_time_correction"></marker> + <p>Returns a boolean value indicating whether + <seealso marker="time_correction#Time_Correction"> + time correction</seealso> is enabled or not.</p> + </item> + <tag><c>time_offset</c></tag> + <item> + <marker id="system_info_time_offset"></marker> + <p>Returns the state of the time offset:</p> + <taglist> + <tag><c>preliminary</c></tag> + <item> + <p>The time offset is preliminary, and will be changed + and finalized later. The preliminary time offset + is used during the preliminary phase of the + <seealso marker="time_correction#Single_Time_Warp_Mode"> + single time warp mode</seealso>.</p> + </item> + <tag><c>final</c></tag> + <item> + <p>The time offset is final. This either because + <seealso marker="time_correction#No_Time_Warp_Mode"> + no time warp mode</seealso> is used, or because the time + offset have been finalized when + <seealso marker="time_correction#Single_Time_Warp_Mode"> + single time warp mode</seealso> is used.</p> + </item> + <tag><c>volatile</c></tag> + <item> + <p>The time offset is volatile. That is, it can + change at any time. This is because + <seealso marker="time_correction#Multi_Time_Warp_Mode"> + multi-time warp mode</seealso> is used.</p> + </item> + </taglist> + </item> + <tag><marker id="system_info_time_warp_mode"/> + <c>time_warp_mode</c></tag> + <item> + <p>Returns a value identifying the + <seealso marker="time_correction#Time_Warp_Modes"> + time warp mode</seealso> that is used:</p> + <taglist> + <tag><c>no_time_warp</c></tag> + <item>The <seealso marker="time_correction#No_Time_Warp_Mode"> + no time warp mode</seealso> is used. + </item> + <tag><c>single_time_warp</c></tag> + <item>The <seealso marker="time_correction#Single_Time_Warp_Mode"> + single time warp mode</seealso> is used. + </item> + <tag><c>multi_time_warp</c></tag> + <item>The <seealso marker="time_correction#Multi_Time_Warp_Mode"> + multi-time warp mode</seealso> is used. + </item> + </taglist> + </item> <tag><c>tolerant_timeofday</c></tag> <item> - <marker id="system_info_tolerant_timeofday"></marker> - <p>Returns whether a pre erts-7.0 backwards compatible compensation - for sudden changes of system time is <c>enabled</c> or <c>disabled</c>. - Such compensation is <c>enabled</c> when the - <seealso marker="#system_info_time_offset">time offset</seealso> is - <c>final</c>, and - <seealso marker="#system_info_time_correction">time correction</seealso> - is enabled.</p> + <marker id="system_info_tolerant_timeofday"></marker> + <p>Returns whether a pre <c>ERTS</c> 7.0 backwards compatible + compensation for sudden changes of system time is <c>enabled</c> + or <c>disabled</c>. Such compensation is <c>enabled</c> when the + <seealso marker="#system_info_time_offset">time offset</seealso> + is <c>final</c>, and + <seealso marker="#system_info_time_correction"> + time correction</seealso> is enabled.</p> </item> <tag><c>trace_control_word</c></tag> <item> <p>Returns the value of the node trace control word. For - more information, see function <c>get_tcw</c> in Section - <seealso marker="erts:match_spec#get_tcw">Match Specifications in Erlang</seealso> in the User's Guide.</p> + more information, see function <c>get_tcw</c> in section + <seealso marker="erts:match_spec#get_tcw"> + Match Specifications in Erlang</seealso> in the User's Guide.</p> </item> <tag><c>update_cpu_info</c></tag> <item> - <marker id="update_cpu_info"></marker> + <marker id="update_cpu_info"></marker> <p>The runtime system rereads the CPU information available - and updates its internally stored information about the - <seealso marker="#system_info_cpu_topology_detected">detected - CPU topology</seealso> and the number of logical processors - <seealso marker="#logical_processors">configured</seealso>, - <seealso marker="#logical_processors_online">online</seealso>, and - <seealso marker="#logical_processors_available">available</seealso>.</p> - <p>If the CPU information has changed since the last time - it was read, the atom <c>changed</c> is returned, otherwise - the atom <c>unchanged</c>. If the CPU information has changed, - you probably want to - <seealso marker="#system_flag_schedulers_online">adjust the - number of schedulers online</seealso>. You typically want - to have as many schedulers online as - <seealso marker="#logical_processors_available">logical - processors available</seealso>.</p> + and updates its internally stored information about the + <seealso marker="#system_info_cpu_topology_detected">detected + CPU topology</seealso> and the number of logical processors + <seealso marker="#logical_processors">configured</seealso>, + <seealso marker="#logical_processors_online">online</seealso>, + and <seealso marker="#logical_processors_available"> + available</seealso>.</p> + <p>If the CPU information has changed since the last time + it was read, the atom <c>changed</c> is returned, otherwise + the atom <c>unchanged</c>. If the CPU information has changed, + you probably want to + <seealso marker="#system_flag_schedulers_online">adjust the + number of schedulers online</seealso>. You typically want + to have as many schedulers online as + <seealso marker="#logical_processors_available">logical + processors available</seealso>.</p> </item> <tag><c>version</c></tag> <item> - <marker id="system_info_version"></marker> + <marker id="system_info_version"></marker> <p>Returns a string containing the version number of the emulator.</p> </item> @@ -8070,11 +8254,11 @@ ok </item> <tag><c>{wordsize, external}</c></tag> <item> - <p>Returns the true word size of the emulator, that is, - the size of a pointer. The value is given in bytes - as an integer. On a pure 32-bit architecture, 4 is - returned. On both a half word and on a pure - 64-bit architecture, 8 is returned.</p> + <p>Returns the true word size of the emulator, that is, + the size of a pointer. The value is given in bytes + as an integer. On a pure 32-bit architecture, 4 is + returned. On both a half word and on a pure + 64-bit architecture, 8 is returned.</p> </item> </taglist> <note> @@ -8093,32 +8277,35 @@ ok <type name="system_monitor_option"/> <desc> <p>Returns the current system monitoring settings set by - <seealso marker="#system_monitor/2">erlang:system_monitor/2</seealso> + <seealso marker="#system_monitor/2"> + <c>erlang:system_monitor/2</c></seealso> as <c>{<anno>MonitorPid</anno>, <anno>Options</anno>}</c>, - or <c>undefined</c> if there - are no settings. The order of the options can be different - from the one that was set.</p> + or <c>undefined</c> if no settings exist. The order of the + options can be different from the one that was set.</p> </desc> </func> <func> <name name="system_monitor" arity="1"/> - <fsummary>Sets or clears system performance monitoring options.</fsummary> + <fsummary>Set or clear system performance monitoring options.</fsummary> <type name="system_monitor_option"/> <desc> <p>When called with argument <c>undefined</c>, all system performance monitoring settings are cleared.</p> <p>Calling the function with <c>{<anno>MonitorPid</anno>, <anno>Options</anno>}</c> as argument is the same as calling - <seealso marker="#system_monitor/2"><c>erlang:system_monitor(<anno>MonitorPid</anno>, <anno>Options</anno>)</c></seealso>.</p> + <seealso marker="#system_monitor/2"> + <c>erlang:system_monitor(<anno>MonitorPid</anno>, + <anno>Options</anno>)</c></seealso>.</p> <p>Returns the previous system monitor settings just like - <seealso marker="#system_monitor/0">erlang:system_monitor/0</seealso>.</p> + <seealso marker="#system_monitor/0"> + <c>erlang:system_monitor/0</c></seealso>.</p> </desc> </func> <func> <name name="system_monitor" arity="2"/> - <fsummary>Sets system performance monitoring options.</fsummary> + <fsummary>Set system performance monitoring options.</fsummary> <type name="system_monitor_option"/> <desc> <p>Sets the system performance monitoring options. @@ -8137,12 +8324,12 @@ ok <p>One of the tuples is <c>{timeout, GcTime}</c>, where <c>GcTime</c> is the time for the garbage collection in milliseconds. The other tuples are - tagged with <c>heap_size</c>, <c>heap_block_size</c> + tagged with <c>heap_size</c>, <c>heap_block_size</c>, <c>stack_size</c>, <c>mbuf_size</c>, <c>old_heap_size</c>, and <c>old_heap_block_size</c>. These tuples are explained in the description of trace message - <seealso marker="#gc_minor_start">gc_minor_start</seealso> (see - <seealso marker="#trace/3">erlang:trace/3</seealso>). + <seealso marker="#gc_minor_start"><c>gc_minor_start</c></seealso> + (see <seealso marker="#trace/3"><c>erlang:trace/3</c></seealso>). New tuples can be added, and the order of the tuples in the <c>Info</c> list can be changed at any time without prior notice.</p> @@ -8173,7 +8360,7 @@ ok <c>timeout</c>, <c>ready_input</c>, <c>ready_output</c>, <c>event</c>, and <c>outputv</c> (when the port is used by distribution). Value <c>Millis</c> in - the <c>timeout</c> tuple informs about the + tuple <c>timeout</c> informs about the uninterrupted execution time of the process or port, which always is equal to or higher than the <c>Time</c> value supplied when starting the trace. New tuples can be @@ -8184,7 +8371,7 @@ ok drivers that take too long to execute. 1 ms is considered a good maximum time for a driver callback or a NIF. However, a time-sharing system is usually to - consider everything below 100 ms as "possible" and + consider everything < 100 ms as "possible" and fairly "normal". However, longer schedule times can indicate swapping or a misbehaving NIF/driver. Misbehaving NIFs and drivers can cause bad resource @@ -8202,10 +8389,11 @@ ok <p>The monitor message is sent if the sum of the sizes of all memory blocks allocated for all heap generations after a garbage collection is equal to or higher than <c>Size</c>.</p> - <p>When a process is killed by <seealso marker="#process_flag_max_heap_size"> + <p>When a process is killed by + <seealso marker="#process_flag_max_heap_size"> <c>max_heap_size</c></seealso>, it is killed before the garbage collection is complete and thus no large heap message - will be sent.</p> + is sent.</p> </item> <tag><c>busy_port</c></tag> <item> @@ -8227,7 +8415,8 @@ ok </item> </taglist> <p>Returns the previous system monitor settings just like - <seealso marker="#system_monitor/0">erlang:system_monitor/0</seealso>.</p> + <seealso marker="#system_monitor/0"> + <c>erlang:system_monitor/0</c></seealso>.</p> <note> <p>If a monitoring process gets so large that it itself starts to cause system monitor messages when garbage @@ -8252,7 +8441,8 @@ ok <type name="system_profile_option"/> <desc> <p>Returns the current system profiling settings set by - <seealso marker="#system_profile/2">erlang:system_profile/2</seealso> + <seealso marker="#system_profile/2"> + <c>erlang:system_profile/2</c></seealso> as <c>{<anno>ProfilerPid</anno>, <anno>Options</anno>}</c>, or <c>undefined</c> if there are no settings. The order of the options can be different @@ -8272,106 +8462,116 @@ ok <taglist> <tag><c>exclusive</c></tag> <item> - <p>If a synchronous call to a port from a process is done, the - calling process is considered not runnable during the call - runtime to the port. The calling process is notified as - <c>inactive</c>, and later <c>active</c> when the port - callback returns.</p> + <p>If a synchronous call to a port from a process is done, the + calling process is considered not runnable during the call + runtime to the port. The calling process is notified as + <c>inactive</c>, and later <c>active</c> when the port + callback returns.</p> </item> <tag><c>monotonic_timestamp</c></tag> <item> - <p>Timestamps in profile messages will use - <seealso marker="time_correction#Erlang_Monotonic_Time">Erlang - monotonic time</seealso>. The time-stamp (Ts) has the same - format and value as produced by - <c>erlang:monotonic_time(nano_seconds)</c>.</p> + <p>Time stamps in profile messages use + <seealso marker="time_correction#Erlang_Monotonic_Time">Erlang + monotonic time</seealso>. The time stamp (Ts) has the same + format and value as produced by + <c>erlang:monotonic_time(nano_seconds)</c>.</p> </item> <tag><c>runnable_procs</c></tag> <item> - <p>If a process is put into or removed from the run queue, a - message, <c>{profile, Pid, State, Mfa, Ts}</c>, is sent to - <c><anno>ProfilerPid</anno></c>. Running processes that - are reinserted into the run queue after having been - preempted do not trigger this message.</p> + <p>If a process is put into or removed from the run queue, a + message, <c>{profile, Pid, State, Mfa, Ts}</c>, is sent to + <c><anno>ProfilerPid</anno></c>. Running processes that + are reinserted into the run queue after having been + pre-empted do not trigger this message.</p> </item> <tag><c>runnable_ports</c></tag> <item> - <p>If a port is put into or removed from the run queue, a - message, <c>{profile, Port, State, 0, Ts}</c>, is sent to - <c><anno>ProfilerPid</anno></c>.</p> + <p>If a port is put into or removed from the run queue, a + message, <c>{profile, Port, State, 0, Ts}</c>, is sent to + <c><anno>ProfilerPid</anno></c>.</p> </item> <tag><c>scheduler</c></tag> <item> - <p>If a scheduler is put to sleep or awoken, a message, - <c>{profile, scheduler, Id, State, NoScheds, Ts}</c>, is - sent to <c><anno>ProfilerPid</anno></c>.</p> + <p>If a scheduler is put to sleep or awoken, a message, + <c>{profile, scheduler, Id, State, NoScheds, Ts}</c>, is + sent to <c><anno>ProfilerPid</anno></c>.</p> </item> <tag><c>strict_monotonic_timestamp</c></tag> <item> - <p>Timestamps in profile messages will consisting of - <seealso marker="time_correction#Erlang_Monotonic_Time">Erlang - monotonic time</seealso> and a monotonically increasing - integer. The time-stamp (Ts) has the same format and value - as produced by <c>{erlang:monotonic_time(nano_seconds), - erlang:unique_integer([monotonic])}</c>.</p> + <p>Time stamps in profile messages consist of + <seealso marker="time_correction#Erlang_Monotonic_Time">Erlang + monotonic time</seealso> and a monotonically increasing + integer. The time stamp (Ts) has the same format and value + as produced by <c>{erlang:monotonic_time(nano_seconds), + erlang:unique_integer([monotonic])}</c>.</p> </item> <tag><c>timestamp</c></tag> <item> - <p>Timestamps in profile messages will include a - time-stamp (Ts) that has the same form as returned by - <c>erlang:now()</c>. This is also the default if no - timestamp flag is given. If <c>cpu_timestamp</c> has - been enabled via <c>erlang:trace/3</c>, this will also - effect the timestamp produced in profiling messages - when <c>timestamp</c> flag is enabled.</p> + <p>Time stamps in profile messages include a + time stamp (Ts) that has the same form as returned by + <c>erlang:now()</c>. This is also the default if no + time stamp flag is specified. If <c>cpu_timestamp</c> has + been enabled through + <seealso marker="erlang:trace/3"><c>erlang:trace/3</c></seealso>, + this also effects the time stamp produced in profiling messages + when flag <c>timestamp</c> is enabled.</p> </item> </taglist> - <note><p><c>erlang:system_profile</c> is considered experimental - and its behavior can change in a future release.</p> + <note> + <p><c>erlang:system_profile</c> behavior can change + in a future release.</p> </note> </desc> </func> + <func> <name name="system_time" arity="0"/> - <fsummary>Current Erlang system time</fsummary> - <desc> - <p>Returns current - <seealso marker="time_correction#Erlang_System_Time">Erlang system time</seealso> - in <c>native</c> - <seealso marker="#type_time_unit">time unit</seealso>.</p> - - <p>Calling <c>erlang:system_time()</c> is equivalent to: - <seealso marker="#monotonic_time/0"><c>erlang:monotonic_time()</c></seealso><c> - + - </c><seealso marker="#time_offset/0"><c>erlang:time_offset()</c></seealso>.</p> - - <note><p>This time is <em>not</em> a monotonically increasing time - in the general case. For more information, see the documentation of - <seealso marker="time_correction#Time_Warp_Modes">time warp modes</seealso> in the - ERTS User's Guide.</p></note> + <fsummary>Current Erlang system time.</fsummary> + <desc> + <p>Returns current + <seealso marker="time_correction#Erlang_System_Time"> + Erlang system time</seealso> in <c>native</c> + <seealso marker="#type_time_unit">time unit</seealso>.</p> + <p>Calling <c>erlang:system_time()</c> is equivalent to + <seealso marker="#monotonic_time/0"> + <c>erlang:monotonic_time()</c></seealso><c> + + </c><seealso marker="#time_offset/0"> + <c>erlang:time_offset()</c></seealso>.</p> + <note> + <p>This time is <em>not</em> a monotonically increasing time + in the general case. For more information, see the documentation of + <seealso marker="time_correction#Time_Warp_Modes"> + time warp modes</seealso> in the User's Guide.</p> + </note> </desc> </func> + <func> <name name="system_time" arity="1"/> - <fsummary>Current Erlang system time</fsummary> - <desc> - <p>Returns current - <seealso marker="time_correction#Erlang_System_Time">Erlang system time</seealso> - converted into the <c><anno>Unit</anno></c> passed as argument.</p> - - <p>Calling <c>erlang:system_time(<anno>Unit</anno>)</c> is equivalent to: - <seealso marker="#convert_time_unit/3"><c>erlang:convert_time_unit</c></seealso><c>(</c><seealso marker="#system_time/0"><c>erlang:system_time()</c></seealso><c>, - native, <anno>Unit</anno>)</c>.</p> - - <note><p>This time is <em>not</em> a monotonically increasing time - in the general case. For more information, see the documentation of - <seealso marker="time_correction#Time_Warp_Modes">time warp modes</seealso> in the - ERTS User's Guide.</p></note> + <fsummary>Current Erlang system time.</fsummary> + <desc> + <p>Returns current + <seealso marker="time_correction#Erlang_System_Time"> + Erlang system time</seealso> + converted into the <c><anno>Unit</anno></c> passed as argument.</p> + <p>Calling <c>erlang:system_time(<anno>Unit</anno>)</c> is equivalent + to <seealso marker="#convert_time_unit/3"> + <c>erlang:convert_time_unit</c></seealso><c>(</c><seealso + marker="#system_time/0"><c>erlang:system_time()</c></seealso><c>, + native, <anno>Unit</anno>)</c>.</p> + <note> + <p>This time is <em>not</em> a monotonically increasing time + in the general case. For more information, see the documentation of + <seealso marker="time_correction#Time_Warp_Modes"> + time warp modes</seealso> in the User's Guide.</p> + </note> </desc> </func> + <func> <name name="term_to_binary" arity="1"/> - <fsummary>Encodes a term to an Erlang external term format binary.</fsummary> + <fsummary>Encode a term to an Erlang external term format binary. + </fsummary> <desc> <p>Returns a binary data object that is the result of encoding <c><anno>Term</anno></c> according to the Erlang external @@ -8380,64 +8580,65 @@ ok writing a term to a file in an efficient way, or sending an Erlang term to some type of communications channel not supported by distributed Erlang.</p> - <p>See also - <seealso marker="#binary_to_term/1">binary_to_term/1</seealso>.</p> + <p>See also <seealso marker="#binary_to_term/1"> + <c>binary_to_term/1</c></seealso>.</p> </desc> </func> <func> <name name="term_to_binary" arity="2"/> - <fsummary>Encodes a term to en Erlang external term format binary.</fsummary> + <fsummary>Encode a term to en Erlang external term format binary. + </fsummary> <desc> <p>Returns a binary data object that is the result of encoding <c><anno>Term</anno></c> according to the Erlang external term format.</p> <p>If option <c>compressed</c> is provided, the external term format is compressed. The compressed format is automatically - recognized by <c>binary_to_term/1</c> as from Erlang R7B.</p> + recognized by <c>binary_to_term/1</c> as from Erlang/OTP R7B.</p> <p>A compression level can be specified by giving option <c>{compressed, <anno>Level</anno>}</c>. <c><anno>Level</anno></c> is an integer with range 0..9, where:</p> <list type="bulleted"> - <item><c>0</c> - No compression is done (it is the same as - giving no <c>compressed</c> option).</item> - <item><c>1</c> - Takes least time but may not compress - as well as the higher levels.</item> - <item><c>6</c> - Default level when option <c>compressed</c> - is provided.</item> - <item><c>9</c> - Takes most time and tries to produce a smaller + <item><p><c>0</c> - No compression is done (it is the same as + giving no <c>compressed</c> option).</p></item> + <item><p><c>1</c> - Takes least time but may not compress + as well as the higher levels.</p></item> + <item><p><c>6</c> - Default level when option <c>compressed</c> + is provided.</p></item> + <item><p><c>9</c> - Takes most time and tries to produce a smaller result. Notice "tries" in the preceding sentence; depending on the input term, level 9 compression either does or does - not produce a smaller result than level 1 compression.</item> + not produce a smaller result than level 1 compression.</p></item> </list> <p>Option <c>{minor_version, <anno>Version</anno>}</c> - can be used to control - some encoding details. This option was introduced in OTP R11B-4. + can be used to control some + encoding details. This option was introduced in Erlang/OTP R11B-4. The valid values for <c><anno>Version</anno></c> are <c>0</c> and <c>1</c>.</p> - <p>As from OTP 17.0, <c>{minor_version, 1}</c> is the default. It + <p>As from Erlang/OTP 17.0, <c>{minor_version, 1}</c> is the default. It forces any floats in the term to be encoded in a more space-efficient and exact way (namely in the 64-bit IEEE format, rather than converted to a textual representation).</p> - <p>As from OTP R11B-4, <c>binary_to_term/1</c> can decode this + <p>As from Erlang/OTP R11B-4, <c>binary_to_term/1</c> can decode this representation.</p> <p><c>{minor_version, 0}</c> means that floats are encoded using a textual representation. This option is useful to - ensure that releases before OTP R11B-4 can decode resulting + ensure that releases before Erlang/OTP R11B-4 can decode resulting binary.</p> - <p>See also - <seealso marker="#binary_to_term/1">binary_to_term/1</seealso>.</p> + <p>See also <seealso marker="#binary_to_term/1"> + <c>binary_to_term/1</c></seealso>.</p> </desc> </func> <func> <name name="throw" arity="1"/> - <fsummary>Throws an exception.</fsummary> + <fsummary>Throw an exception.</fsummary> <desc> <p>A non-local return from a function. If evaluated within a - <c>catch</c>, <c>catch</c> returns value <c><anno>Any</anno></c>.</p> - <p>Example:</p> + <c>catch</c>, <c>catch</c> returns value <c><anno>Any</anno></c>. + Example:</p> <pre> > <input>catch throw({hello, there}).</input> {hello,there}</pre> @@ -8451,8 +8652,7 @@ ok <desc> <p>Returns the current time as <c>{Hour, Minute, Second}</c>.</p> <p>The time zone and Daylight Saving Time correction depend on - the underlying OS.</p> - <p>Example:</p> + the underlying OS. Example:</p> <pre> > <input>time().</input> {9,42,44}</pre> @@ -8461,86 +8661,94 @@ ok <func> <name name="time_offset" arity="0"/> - <fsummary>Current time offset</fsummary> - <desc> - <p>Returns the current time offset between - <seealso marker="time_correction#Erlang_Monotonic_Time">Erlang monotonic time</seealso> - and - <seealso marker="time_correction#Erlang_System_Time">Erlang system time</seealso> in - <c>native</c> <seealso marker="#type_time_unit">time unit</seealso>. - Current time offset added to an Erlang monotonic time gives - corresponding Erlang system time.</p> - - <p>The time offset may or may not change during operation depending - on the <seealso marker="time_correction#Time_Warp_Modes">time - warp mode</seealso> used.</p> - - <note> - <p>A change in time offset may be observed at slightly - different points in time by different processes.</p> - - <p>If the runtime system is in - <seealso marker="time_correction#Multi_Time_Warp_Mode">multi - time warp mode</seealso>, the time offset will be changed when - the runtime system detects that the - <seealso marker="time_correction#OS_System_Time">OS system - time</seealso> has changed. The runtime system will, however, - not detect this immediately when it happens. A task checking - the time offset is scheduled to execute at least once a minute, - so under normal operation this should be detected within a - minute, but during heavy load it might take longer time.</p> - </note> + <fsummary>Current time offset.</fsummary> + <desc> + <p>Returns the current time offset between + <seealso marker="time_correction#Erlang_Monotonic_Time"> + Erlang monotonic time</seealso> and + <seealso marker="time_correction#Erlang_System_Time"> + Erlang system time</seealso> in + <c>native</c> <seealso marker="#type_time_unit">time unit</seealso>. + Current time offset added to an Erlang monotonic time gives + corresponding Erlang system time.</p> + <p>The time offset may or may not change during operation depending + on the <seealso marker="time_correction#Time_Warp_Modes">time + warp mode</seealso> used.</p> + <note> + <p>A change in time offset can be observed at slightly + different points in time by different processes.</p> + <p>If the runtime system is in + <seealso marker="time_correction#Multi_Time_Warp_Mode">multi-time + warp mode</seealso>, the time offset is changed when + the runtime system detects that the + <seealso marker="time_correction#OS_System_Time">OS system + time</seealso> has changed. The runtime system will, however, + not detect this immediately when it occurs. A task checking + the time offset is scheduled to execute at least once a minute; + so, under normal operation this is to be detected within a + minute, but during heavy load it can take longer time.</p> + </note> </desc> </func> + <func> <name name="time_offset" arity="1"/> - <fsummary>Current time offset</fsummary> + <fsummary>Current time offset.</fsummary> <desc> - <p>Returns the current time offset between - <seealso marker="time_correction#Erlang_Monotonic_Time">Erlang monotonic time</seealso> - and - <seealso marker="time_correction#Erlang_System_Time">Erlang system time</seealso> - converted into the <c><anno>Unit</anno></c> passed as argument.</p> - - <p>Same as calling - <seealso marker="#convert_time_unit/3"><c>erlang:convert_time_unit</c></seealso><c>(</c><seealso marker="#time_offset/0"><c>erlang:time_offset()</c></seealso><c>, native, <anno>Unit</anno>)</c> - however optimized for commonly used <c><anno>Unit</anno></c>s.</p> + <p>Returns the current time offset between + <seealso marker="time_correction#Erlang_Monotonic_Time"> + Erlang monotonic time</seealso> and + <seealso marker="time_correction#Erlang_System_Time"> + Erlang system time</seealso> + converted into the <c><anno>Unit</anno></c> passed as argument.</p> + <p>Same as calling + <seealso marker="#convert_time_unit/3"> + <c>erlang:convert_time_unit</c></seealso><c>(</c><seealso marker="#time_offset/0"> + <c>erlang:time_offset()</c></seealso><c>, native, + <anno>Unit</anno>)</c> + however optimized for commonly used <c><anno>Unit</anno></c>s.</p> </desc> </func> + <func> <name name="timestamp" arity="0"/> - <fsummary>Current Erlang System time</fsummary> + <fsummary>Current Erlang System time.</fsummary> <type name="timestamp"/> <desc> - <p>Returns current - <seealso marker="time_correction#Erlang_System_Time">Erlang system time</seealso> - on the format <c>{MegaSecs, Secs, MicroSecs}</c>. This format is - the same as <seealso marker="kernel:os#timestamp/0"><c>os:timestamp/0</c></seealso> - and the deprecated <seealso marker="#now/0"><c>erlang:now/0</c></seealso> - uses. The reason for the existence of <c>erlang:timestamp()</c> is - purely to simplify usage for existing code that assumes this timestamp - format. Current Erlang system time can more efficiently be retrieved in - the time unit of your choice using - <seealso marker="#system_time/1"><c>erlang:system_time/1</c></seealso>.</p> - - <p>The <c>erlang:timestamp()</c> BIF is equivalent to:</p><code type="none"> + <p>Returns current + <seealso marker="time_correction#Erlang_System_Time"> + Erlang system time</seealso> + on the format <c>{MegaSecs, Secs, MicroSecs}</c>. This format is + the same as <seealso marker="kernel:os#timestamp/0"> + <c>os:timestamp/0</c></seealso> + and the deprecated <seealso marker="#now/0"> + <c>erlang:now/0</c></seealso> + use. The reason for the existence of <c>erlang:timestamp()</c> is + purely to simplify use for existing code that assumes this time stamp + format. Current Erlang system time can more efficiently be retrieved + in the time unit of your choice using + <seealso marker="#system_time/1"> + <c>erlang:system_time/1</c></seealso>.</p> + <p>The <c>erlang:timestamp()</c> BIF is equivalent to:</p> +<code type="none"> timestamp() -> ErlangSystemTime = erlang:system_time(micro_seconds), MegaSecs = ErlangSystemTime div 1000000000000, Secs = ErlangSystemTime div 1000000 - MegaSecs*1000000, MicroSecs = ErlangSystemTime rem 1000000, {MegaSecs, Secs, MicroSecs}.</code> - <p>It, however, uses a native implementation which does - not build garbage on the heap and with slightly better - performance.</p> - - <note><p>This time is <em>not</em> a monotonically increasing time - in the general case. For more information, see the documentation of - <seealso marker="time_correction#Time_Warp_Modes">time warp modes</seealso> in the - ERTS User's Guide.</p></note> + <p>It, however, uses a native implementation that does + not build garbage on the heap and with slightly better + performance.</p> + <note> + <p>This time is <em>not</em> a monotonically increasing time + in the general case. For more information, see the documentation of + <seealso marker="time_correction#Time_Warp_Modes"> + time warp modes</seealso> in the User's Guide.</p> + </note> </desc> - </func> + <func> <name name="tl" arity="1"/> <fsummary>Tail of a list.</fsummary> @@ -8558,7 +8766,7 @@ timestamp() -> <func> <name name="trace" arity="3"/> - <fsummary>Sets trace flags for a process or processes.</fsummary> + <fsummary>Set trace flags for a process or processes.</fsummary> <type name="trace_flag"/> <desc> <p>Turns on (if <c><anno>How</anno> == true</c>) or off (if @@ -8568,49 +8776,43 @@ timestamp() -> <c><anno>PidPortSpec</anno></c>.</p> <p><c><anno>PidPortSpec</anno></c> is either a process identifier (pid) for a local process, a port identifier, - or one of the following atoms:</p> + or one of the following atoms:</p> <taglist> <tag><c>all</c></tag> - <item> - <p>All currently existing processes and ports and all that - will be created in the future.</p> + <item>All currently existing processes and ports and all that + will be created in the future. </item> <tag><c>processes</c></tag> - <item> - <p>All currently existing processes and all that will be created in the future.</p> + <item>All currently existing processes and all that will be created + in the future. </item> <tag><c>ports</c></tag> - <item> - <p>All currently existing ports and all that will be created in the future.</p> + <item>All currently existing ports and all that will be created in + the future. </item> <tag><c>existing</c></tag> - <item> - <p>All currently existing processes and ports.</p> + <item>All currently existing processes and ports. </item> <tag><c>existing_processes</c></tag> - <item> - <p>All currently existing processes.</p> + <item>All currently existing processes. </item> <tag><c>existing_ports</c></tag> - <item> - <p>All currently existing ports.</p> + <item>All currently existing ports. </item> <tag><c>new</c></tag> - <item> - <p>All processes and ports that will be created in the future.</p> + <item>All processes and ports that will be created in the future. </item> <tag><c>new_processes</c></tag> - <item> - <p>All processes that will be created in the future.</p> + <item>All processes that will be created in the future. </item> <tag><c>new_ports</c></tag> - <item> - <p>All ports that will be created in the future.</p> + <item>All ports that will be created in the future. </item> </taglist> <p><c><anno>FlagList</anno></c> can contain any number of the following flags (the "message tags" refers to the list of - <seealso marker="#trace_3_trace_messages">trace messages</seealso>):</p> + <seealso marker="#trace_3_trace_messages"> + <c>trace messages</c></seealso>):</p> <taglist> <tag><c>all</c></tag> <item> @@ -8621,21 +8823,29 @@ timestamp() -> <tag><c>send</c></tag> <item> <p>Traces sending of messages.</p> - <p>Message tags: <seealso marker="#trace_3_trace_messages_send"><c>send</c></seealso> and - <seealso marker="#trace_3_trace_messages_send_to_non_existing_process"><c>send_to_non_existing_process</c></seealso>.</p> + <p>Message tags: + <seealso marker="#trace_3_trace_messages_send"> + <c>send</c></seealso> and + <seealso marker="#trace_3_trace_messages_send_to_non_existing_process"> + <c>send_to_non_existing_process</c></seealso>.</p> </item> <tag><c>'receive'</c></tag> <item> <p>Traces receiving of messages.</p> - <p>Message tags: <seealso marker="#trace_3_trace_messages_receive"><c>'receive'</c></seealso>.</p> + <p>Message tags: + <seealso marker="#trace_3_trace_messages_receive"> + <c>'receive'</c></seealso>.</p> </item> -<tag><c>call</c></tag> + <tag><c>call</c></tag> <item> <p>Traces certain function calls. Specify which function - calls to trace by calling - <seealso marker="#trace_pattern/3">erlang:trace_pattern/3</seealso>.</p> - <p>Message tags: <seealso marker="#trace_3_trace_messages_call"><c>call</c></seealso> and - <seealso marker="#trace_3_trace_messages_return_from"><c>return_from</c></seealso>.</p> + calls to trace by calling <seealso marker="#trace_pattern/3"> + <c>erlang:trace_pattern/3</c></seealso>.</p> + <p>Message tags: + <seealso marker="#trace_3_trace_messages_call"> + <c>call</c></seealso> and + <seealso marker="#trace_3_trace_messages_return_from"> + <c>return_from</c></seealso>.</p> </item> <tag><c>silent</c></tag> <item> @@ -8653,17 +8863,21 @@ timestamp() -> specification function <c>{silent,Bool}</c>, giving a high degree of control of which functions with which arguments that trigger the trace.</p> - <p>Message tags: <seealso marker="#trace_3_trace_messages_call"><c>call</c></seealso>, - <seealso marker="#trace_3_trace_messages_return_from"><c>return_from</c></seealso>, and - <seealso marker="#trace_3_trace_messages_return_to"><c>return_to</c></seealso>. Or rather, the absence of.</p> + <p>Message tags: + <seealso marker="#trace_3_trace_messages_call"> + <c>call</c></seealso>, + <seealso marker="#trace_3_trace_messages_return_from"> + <c>return_from</c></seealso>, and + <seealso marker="#trace_3_trace_messages_return_to"> + <c>return_to</c></seealso>. Or rather, the absence of.</p> </item> <tag><c>return_to</c></tag> <item> <p>Used with the <c>call</c> trace flag. Traces the return from a traced function back to its caller. Only works for functions traced with - option <c>local</c> to - <seealso marker="#trace_pattern/3">erlang:trace_pattern/3</seealso>.</p> + option <c>local</c> to <seealso marker="#trace_pattern/3"> + <c>erlang:trace_pattern/3</c></seealso>.</p> <p>The semantics is that a trace message is sent when a call traced function returns, that is, when a chain of tail recursive calls ends. Only one trace @@ -8676,105 +8890,144 @@ timestamp() -> <p>To get trace messages containing return values from functions, use the <c>{return_trace}</c> match specification action instead.</p> - <p>Message tags: <seealso marker="#trace_3_trace_messages_return_to"><c>return_to</c></seealso>.</p> + <p>Message tags: + <seealso marker="#trace_3_trace_messages_return_to"> + <c>return_to</c></seealso>.</p> </item> <tag><c>procs</c></tag> <item> <p>Traces process-related events.</p> - <p>Message tags: <seealso marker="#trace_3_trace_messages_spawn"><c>spawn</c></seealso>, - <seealso marker="#trace_3_trace_messages_spawned"><c>spawned</c></seealso>, - <seealso marker="#trace_3_trace_messages_exit"><c>exit</c></seealso>, - <seealso marker="#trace_3_trace_messages_register"><c>register</c></seealso>, - <seealso marker="#trace_3_trace_messages_unregister"><c>unregister</c></seealso>, - <seealso marker="#trace_3_trace_messages_link"><c>link</c></seealso>, - <seealso marker="#trace_3_trace_messages_unlink"><c>unlink</c></seealso>, - <seealso marker="#trace_3_trace_messages_getting_linked"><c>getting_linked</c></seealso>, and - <seealso marker="#trace_3_trace_messages_getting_unlinked"><c>getting_unlinked</c></seealso>.</p> + <p>Message tags: + <seealso marker="#trace_3_trace_messages_spawn"> + <c>spawn</c></seealso>, + <seealso marker="#trace_3_trace_messages_spawned"> + <c>spawned</c></seealso>, + <seealso marker="#trace_3_trace_messages_exit"> + <c>exit</c></seealso>, + <seealso marker="#trace_3_trace_messages_register"> + <c>register</c></seealso>, + <seealso marker="#trace_3_trace_messages_unregister"> + <c>unregister</c></seealso>, + <seealso marker="#trace_3_trace_messages_link"> + <c>link</c></seealso>, + <seealso marker="#trace_3_trace_messages_unlink"> + <c>unlink</c></seealso>, + <seealso marker="#trace_3_trace_messages_getting_linked"> + <c>getting_linked</c></seealso>, and + <seealso marker="#trace_3_trace_messages_getting_unlinked"> + <c>getting_unlinked</c></seealso>.</p> </item> <tag><c>ports</c></tag> <item> <p>Traces port-related events.</p> - <p>Message tags: <seealso marker="#trace_3_trace_messages_open"><c>open</c></seealso>, - <seealso marker="#trace_3_trace_messages_closed"><c>closed</c></seealso>, - <seealso marker="#trace_3_trace_messages_register"><c>register</c></seealso>, - <seealso marker="#trace_3_trace_messages_unregister"><c>unregister</c></seealso>, - <seealso marker="#trace_3_trace_messages_getting_linked"><c>getting_linked</c></seealso>, and - <seealso marker="#trace_3_trace_messages_getting_unlinked"><c>getting_unlinked</c></seealso>.</p> + <p>Message tags: + <seealso marker="#trace_3_trace_messages_open"> + <c>open</c></seealso>, + <seealso marker="#trace_3_trace_messages_closed"> + <c>closed</c></seealso>, + <seealso marker="#trace_3_trace_messages_register"> + <c>register</c></seealso>, + <seealso marker="#trace_3_trace_messages_unregister"> + <c>unregister</c></seealso>, + <seealso marker="#trace_3_trace_messages_getting_linked"> + <c>getting_linked</c></seealso>, and + <seealso marker="#trace_3_trace_messages_getting_unlinked"> + <c>getting_unlinked</c></seealso>.</p> </item> <tag><c>running</c></tag> <item> <p>Traces scheduling of processes.</p> - <p>Message tags: <seealso marker="#trace_3_trace_messages_in_proc"><c>in</c></seealso> and - <seealso marker="#trace_3_trace_messages_out_proc"><c>out</c></seealso>.</p> + <p>Message tags: + <seealso marker="#trace_3_trace_messages_in_proc"> + <c>in</c></seealso> and + <seealso marker="#trace_3_trace_messages_out_proc"> + <c>out</c></seealso>.</p> </item> <tag><c>exiting</c></tag> <item> <p>Traces scheduling of exiting processes.</p> - <p>Message tags: <seealso marker="#trace_3_trace_messages_in_exiting_proc"><c>in_exiting</c></seealso>, - <seealso marker="#trace_3_trace_messages_out_exiting_proc"><c>out_exiting</c></seealso>, and - <seealso marker="#trace_3_trace_messages_out_exited_proc"><c>out_exited</c></seealso>.</p> + <p>Message tags: + <seealso marker="#trace_3_trace_messages_in_exiting_proc"> + <c>in_exiting</c></seealso>, + <seealso marker="#trace_3_trace_messages_out_exiting_proc"> + <c>out_exiting</c></seealso>, and + <seealso marker="#trace_3_trace_messages_out_exited_proc"> + <c>out_exited</c></seealso>.</p> </item> <tag><c>running_procs</c></tag> <item> <p>Traces scheduling of processes just like <c>running</c>. - However this option also includes schedule events when the - process executes within the context of a port without - being scheduled out itself.</p> - <p>Message tags: <seealso marker="#trace_3_trace_messages_in_proc"><c>in</c></seealso> and - <seealso marker="#trace_3_trace_messages_out_proc"><c>out</c></seealso>.</p> + However, this option also includes schedule events when the + process executes within the context of a port without + being scheduled out itself.</p> + <p>Message tags: + <seealso marker="#trace_3_trace_messages_in_proc"> + <c>in</c></seealso> and + <seealso marker="#trace_3_trace_messages_out_proc"> + <c>out</c></seealso>.</p> </item> <tag><c>running_ports</c></tag> <item> <p>Traces scheduling of ports.</p> - <p>Message tags: <seealso marker="#trace_3_trace_messages_in_port"><c>in</c></seealso> and - <seealso marker="#trace_3_trace_messages_out_port"><c>out</c></seealso>.</p> + <p>Message tags: + <seealso marker="#trace_3_trace_messages_in_port"> + <c>in</c></seealso> and + <seealso marker="#trace_3_trace_messages_out_port"> + <c>out</c></seealso>.</p> </item> <tag><c>garbage_collection</c></tag> <item> <p>Traces garbage collections of processes.</p> - <p>Message tags: <seealso marker="#trace_3_trace_messages_gc_minor_start"><c>gc_minor_start</c></seealso>, - <seealso marker="#trace_3_trace_messages_gc_max_heap_size"><c>gc_max_heap_size</c></seealso> and - <seealso marker="#trace_3_trace_messages_gc_minor_end"><c>gc_minor_end</c></seealso>.</p> + <p>Message tags: + <seealso marker="#trace_3_trace_messages_gc_minor_start"> + <c>gc_minor_start</c></seealso>, + <seealso marker="#trace_3_trace_messages_gc_max_heap_size"> + <c>gc_max_heap_size</c></seealso>, and + <seealso marker="#trace_3_trace_messages_gc_minor_end"> + <c>gc_minor_end</c></seealso>.</p> </item> <tag><c>timestamp</c></tag> <item> - <p>Includes a time-stamp in all trace messages. The - time-stamp (Ts) has the same form as returned by + <p>Includes a time stamp in all trace messages. The + time stamp (Ts) has the same form as returned by <c>erlang:now()</c>.</p> </item> <tag><c>cpu_timestamp</c></tag> <item> <p>A global trace flag for the Erlang node that makes all - trace time-stamps using the <c>timestamp</c> flag to be - in CPU time, not wall clock time. That is, <c>cpu_timestamp</c> - will not be used if <c>monotonic_timestamp</c>, or - <c>strict_monotonic_timestamp</c> is enabled. + trace time stamps using flag <c>timestamp</c> to be + in CPU time, not wall clock time. That is, <c>cpu_timestamp</c> + is not be used if <c>monotonic_timestamp</c> or + <c>strict_monotonic_timestamp</c> is enabled. Only allowed with <c><anno>PidPortSpec</anno>==all</c>. If the host machine OS does not support high-resolution CPU time measurements, <c>trace/3</c> exits with <c>badarg</c>. Notice that most OS do not synchronize this value across cores, so be prepared - that time might seem to go backwards when using this option.</p> + that time can seem to go backwards when using this option.</p> </item> <tag><c>monotonic_timestamp</c></tag> <item> <p>Includes an - <seealso marker="time_correction#Erlang_Monotonic_Time">Erlang - monotonic time</seealso> time-stamp in all trace messages. The - time-stamp (Ts) has the same format and value as produced by - <seealso marker="#monotonic_time-1"><c>erlang:monotonic_time(nano_seconds)</c></seealso>. - This flag overrides the <c>cpu_timestamp</c> flag.</p> + <seealso marker="time_correction#Erlang_Monotonic_Time">Erlang + monotonic time</seealso> time stamp in all trace messages. The + time stamp (Ts) has the same format and value as produced by + <seealso marker="#monotonic_time-1"> + <c>erlang:monotonic_time(nano_seconds)</c></seealso>. + This flag overrides flag <c>cpu_timestamp</c>.</p> </item> <tag><c>strict_monotonic_timestamp</c></tag> <item> - <p>Includes an timestamp consisting of - <seealso marker="time_correction#Erlang_Monotonic_Time">Erlang - monotonic time</seealso> and a monotonically increasing - integer in all trace messages. The time-stamp (Ts) has the - same format and value as produced by - <c>{</c><seealso marker="#monotonic_time-1"><c>erlang:monotonic_time(nano_seconds)</c></seealso><c>,</c> - <seealso marker="#unique_integer-1"><c>erlang:unique_integer([monotonic])</c></seealso><c>}</c>. - This flag overrides the <c>cpu_timestamp</c> flag.</p> + <p>Includes an time stamp consisting of + <seealso marker="time_correction#Erlang_Monotonic_Time">Erlang + monotonic time</seealso> and a monotonically increasing + integer in all trace messages. The time stamp (Ts) has the + same format and value as produced by <c>{</c> + <seealso marker="#monotonic_time-1"> + <c>erlang:monotonic_time(nano_seconds)</c></seealso><c>,</c> + <seealso marker="#unique_integer-1"> + <c>erlang:unique_integer([monotonic])</c></seealso><c>}</c>. + This flag overrides flag <c>cpu_timestamp</c>.</p> </item> <tag><c>arity</c></tag> <item> @@ -8812,34 +9065,34 @@ timestamp() -> </item> <tag><c>{tracer, TracerModule, TracerState}</c></tag> <item> - <p>Specifies that a tracer module should be called - instead of sending a trace message. The tracer module - can then ignore or change the trace message. For more details - on how to write a tracer module see - <seealso marker="erts:erl_tracer"><c>erl_tracer</c></seealso> - </p> + <p>Specifies that a tracer module is to be called + instead of sending a trace message. The tracer module + can then ignore or change the trace message. For more details + on how to write a tracer module, see + <seealso marker="erts:erl_tracer"><c>erl_tracer(3)</c></seealso>.</p> </item> </taglist> - <p>If no <c>tracer</c> is given, the calling process - will be receiving all of the trace messages</p> + <p>If no <c>tracer</c> is specified, the calling process + receives all the trace messages.</p> <p>The effect of combining <c>set_on_first_link</c> with - <c>set_on_link</c> is the same as having + <c>set_on_link</c> is the same as <c>set_on_first_link</c> alone. Likewise for <c>set_on_spawn</c> and <c>set_on_first_spawn</c>.</p> <p>The tracing process receives the <em>trace messages</em> described - in the following list. <c>Pid</c> is the process identifier of the - traced process in which the traced event has occurred. The - third tuple element is the message tag.</p> + in the following list. <c>Pid</c> is the process identifier of the + traced process in which the traced event has occurred. The + third tuple element is the message tag.</p> <p>If flag <c>timestamp</c>, <c>strict_monotonic_timestamp</c>, or - <c>monotonic_timestamp</c> is given, the first tuple - element is <c>trace_ts</c> instead, and the time-stamp - is added as an extra element last in the message tuple. If - multiple timestamp flags are passed, <c>timestamp</c> has - precedence over <c>strict_monotonic_timestamp</c> which - in turn has precedence over <c>monotonic_timestamp</c>. All - timestamp flags are remembered, so if two are passed - and the one with highest precedence later is disabled - the other one will become active.</p> + <c>monotonic_timestamp</c> is specified, the first tuple + element is <c>trace_ts</c> instead, and the time stamp + is added as an extra element last in the message tuple. If + multiple time stamp flags are passed, <c>timestamp</c> has + precedence over <c>strict_monotonic_timestamp</c>, which + in turn has precedence over <c>monotonic_timestamp</c>. All + time stamp flags are remembered, so if two are passed + and the one with highest precedence later is disabled, + the other one becomes active.</p> + <p>Trace messages:</p> <marker id="trace_3_trace_messages"></marker> <taglist> <tag> @@ -8851,7 +9104,7 @@ timestamp() -> process <c>To</c>.</p> </item> <tag> - <marker id="trace_3_trace_messages_send_to_non_existing_process"></marker> + <marker id="trace_3_trace_messages_send_to_non_existing_process"/> <c>{trace, PidPort, send_to_non_existing_process, Msg, To}</c> </tag> <item> @@ -8864,9 +9117,9 @@ timestamp() -> </tag> <item> <p>When <c>PidPort</c> receives message <c>Msg</c>. - If <c>Msg</c> is set to timeout, then a receive - statement may have timedout, or the process received - a message with the payload <c>timeout</c>.</p> + If <c>Msg</c> is set to time-out, a receive + statement can have timed out, or the process received + a message with the payload <c>timeout</c>.</p> </item> <tag> <marker id="trace_3_trace_messages_call"></marker> @@ -9000,7 +9253,7 @@ timestamp() -> </tag> <item> <p>When <c>Pid</c> opens a new port <c>Port</c> with - the running the <c>Driver</c>.</p> + the running <c>Driver</c>.</p> <p><c>Driver</c> is the name of the driver as an atom.</p> </item> <tag> @@ -9008,7 +9261,7 @@ timestamp() -> <c>{trace, Port, closed, Reason}</c> </tag> <item> - <p>When <c>Port</c> closed with <c>Reason</c>.</p> + <p>When <c>Port</c> closes with <c>Reason</c>.</p> </item> <tag> <marker id="trace_3_trace_messages_in_proc"></marker> @@ -9025,7 +9278,8 @@ timestamp() -> <marker id="trace_3_trace_messages_out_proc"></marker> <marker id="trace_3_trace_messages_out_exiting_proc"></marker> <marker id="trace_3_trace_messages_out_exited_proc"></marker> - <c>{trace, Pid, out | out_exiting | out_exited, {M, F, Arity} | 0}</c> + <c>{trace, Pid, out | out_exiting | out_exited, {M, F, Arity} + | 0}</c> </tag> <item> <p>When <c>Pid</c> is scheduled out. The process was @@ -9039,11 +9293,13 @@ timestamp() -> </tag> <item> <p>When <c>Port</c> is scheduled to run. <c>Command</c> is the - first thing the port will execute, it may however run several - commands before being scheduled out. On some rare - occasions, the current function cannot be determined, - then the last element is <c>0</c>.</p> - <p>The possible commands are: <c>call | close | command | connect | control | flush | info | link | open | unlink</c></p> + first thing the port will execute, it can however run several + commands before being scheduled out. On some rare + occasions, the current function cannot be determined, + then the last element is <c>0</c>.</p> + <p>The possible commands are <c>call</c>, <c>close</c>, + <c>command</c>, <c>connect</c>, <c>control</c>, <c>flush</c>, + <c>info</c>, <c>link</c>, <c>open</c>, and <c>unlink</c>.</p> </item> <tag> <marker id="trace_3_trace_messages_out_port"></marker> @@ -9054,8 +9310,7 @@ timestamp() -> was <c>Command</c>. On some rare occasions, the current function cannot be determined, then the last element is <c>0</c>. <c>Command</c> can contain the same - commands as <c>in</c> - </p> + commands as <c>in</c></p> </item> <tag> <marker id="trace_3_trace_messages_gc_minor_start"></marker> @@ -9071,13 +9326,13 @@ timestamp() -> <taglist> <tag><c>heap_size</c></tag> <item>The size of the used part of the heap.</item> - <tag><c>heap_block_size</c></tag> - <item>The size of the memory block used for storing - the heap and the stack.</item> + <tag><c>heap_block_size</c></tag> + <item>The size of the memory block used for storing + the heap and the stack.</item> <tag><c>old_heap_size</c></tag> <item>The size of the used part of the old heap.</item> - <tag><c>old_heap_block_size</c></tag> - <item>The size of the memory block used for storing + <tag><c>old_heap_block_size</c></tag> + <item>The size of the memory block used for storing the old heap.</item> <tag><c>stack_size</c></tag> <item>The size of the stack.</item> @@ -9091,14 +9346,15 @@ timestamp() -> <item>The total size of unique off-heap binaries referenced from the process heap.</item> <tag><c>bin_vheap_block_size</c></tag> - <item>The total size of binaries allowed in the virtual - heap in the process before doing a garbage collection.</item> + <item>The total size of binaries allowed in the virtual + heap in the process before doing a garbage collection.</item> <tag><c>bin_old_vheap_size</c></tag> <item>The total size of unique off-heap binaries referenced from the process old heap.</item> <tag><c>bin_old_vheap_block_size</c></tag> - <item>The total size of binaries allowed in the virtual - old heap in the process before doing a garbage collection.</item> + <item>The total size of binaries allowed in the virtual + old heap in the process before doing a garbage + collection.</item> </taglist> <p>All sizes are in words.</p> </item> @@ -9107,13 +9363,12 @@ timestamp() -> <c>{trace, Pid, gc_max_heap_size, Info}</c> </tag> <item> - <p> - Sent when the <seealso marker="#process_flag_max_heap_size"><c>max_heap_size</c></seealso> + <p>Sent when the <seealso marker="#process_flag_max_heap_size"> + <c>max_heap_size</c></seealso> is reached during garbage collection. <c>Info</c> contains the same kind of list as in message <c>gc_start</c>, - but the sizes reflect the sizes that triggered max_heap_size to - be reached. - </p> + but the sizes reflect the sizes that triggered + <c>max_heap_size</c> to be reached.</p> </item> <tag> <marker id="trace_3_trace_messages_gc_minor_end"></marker> @@ -9121,7 +9376,8 @@ timestamp() -> </tag> <item> <p>Sent when young garbage collection is finished. <c>Info</c> - contains the same kind of list as in message <c>gc_minor_start</c>, + contains the same kind of list as in message + <c>gc_minor_start</c>, but the sizes reflect the new sizes after garbage collection.</p> </item> @@ -9130,8 +9386,9 @@ timestamp() -> <c>{trace, Pid, gc_major_start, Info}</c> </tag> <item> - <p>Sent when fullsweep garbage collection is about to be started. <c>Info</c> - contains the same kind of list as in message <c>gc_minor_start</c>.</p> + <p>Sent when fullsweep garbage collection is about to be started. + <c>Info</c> contains the same kind of list as in message + <c>gc_minor_start</c>.</p> </item> <tag> <marker id="trace_3_trace_messages_gc_major_end"></marker> @@ -9139,15 +9396,16 @@ timestamp() -> </tag> <item> <p>Sent when fullsweep garbage collection is finished. <c>Info</c> - contains the same kind of list as in message <c>gc_minor_start</c> - but the sizes reflect the new sizes after a fullsweep garbage collection.</p> + contains the same kind of list as in message + <c>gc_minor_start</c>, but the sizes reflect the new sizes after + a fullsweep garbage collection.</p> </item> </taglist> <p>If the tracing process/port dies or the tracer module returns - <c>remove</c>, the flags are silently removed.</p> + <c>remove</c>, the flags are silently removed.</p> <p>Each process can only be traced by one tracer. Therefore, attempts to trace an already traced process fail.</p> - <p>Returns: A number indicating the number of processes that + <p>Returns a number indicating the number of processes that matched <c><anno>PidPortSpec</anno></c>. If <c><anno>PidPortSpec</anno></c> is a process identifier, the return value is <c>1</c>. @@ -9167,22 +9425,24 @@ timestamp() -> <fsummary>Notification when trace has been delivered.</fsummary> <desc> <p>The delivery of trace messages (generated by - <seealso marker="#trace/3"><c>erlang:trace/3</c></seealso>, - <seealso marker="kernel:seq_trace"><c>seq_trace</c></seealso> or - <seealso marker="#system_profile/2"><c>erlang:system_profile/2</c></seealso>) + <seealso marker="#trace/3"><c>erlang:trace/3</c></seealso>, + <seealso marker="kernel:seq_trace"><c>kernel:seq_trace(3)</c></seealso>, + or <seealso marker="#system_profile/2"> + <c>erlang:system_profile/2</c></seealso>) is dislocated on the time-line compared to other events in the system. If you know that <c><anno>Tracee</anno></c> has passed some specific point in its execution, and you want to know when at least all trace messages corresponding to events up to this point have reached the - tracer, use <c>erlang:trace_delivered(<anno>Tracee</anno>)</c>. A - <c>{trace_delivered, <anno>Tracee</anno>, <anno>Ref</anno>}</c> message is sent to - the caller of <c>erlang:trace_delivered(<anno>Tracee</anno>)</c> when it - is guaranteed that all trace messages are delivered to + tracer, use <c>erlang:trace_delivered(<anno>Tracee</anno>)</c>.</p> + <p>When it is guaranteed that all trace messages are delivered to the tracer up to the point that <c><anno>Tracee</anno></c> reached at the time of the call to - <c>erlang:trace_delivered(<anno>Tracee</anno>)</c>.</p> + <c>erlang:trace_delivered(<anno>Tracee</anno>)</c>, then a + <c>{trace_delivered, <anno>Tracee</anno>, <anno>Ref</anno>}</c> + message is sent to the caller of + <c>erlang:trace_delivered(<anno>Tracee</anno>)</c> .</p> <p>Notice that message <c>trace_delivered</c> does <em>not</em> imply that trace messages have been delivered. Instead it implies that all trace messages that @@ -9192,22 +9452,22 @@ timestamp() -> <em>no</em> trace messages have been delivered when the <c>trace_delivered</c> message arrives.</p> <p>Notice that <c><anno>Tracee</anno></c> must refer - to a process currently, + to a process currently or previously existing on the same node as the caller of <c>erlang:trace_delivered(<anno>Tracee</anno>)</c> resides on. The special <c><anno>Tracee</anno></c> atom <c>all</c> denotes all processes that currently are traced in the node.</p> - <p>When used together with an <seealso marker="erts:erl_tracer"> - Tracer Module</seealso> any message sent in the trace callback - is guaranteed to have reached it's recipient before the + <p>When used together with a <seealso marker="erts:erl_tracer"> + Tracer Module</seealso>, any message sent in the trace callback + is guaranteed to have reached its recipient before the <c>trace_delivered</c> message is sent.</p> <p>Example: Process <c>A</c> is <c><anno>Tracee</anno></c>, - port <c>B</c> is tracer, and process <c>C</c> is the port - owner of <c>B</c>. <c>C</c> wants to close <c>B</c> when - <c>A</c> exits. To ensure that the trace is not truncated, - <c>C</c> can call <c>erlang:trace_delivered(A)</c>, when - <c>A</c> exits, and wait for message <c>{trace_delivered, A, - <anno>Ref</anno>}</c> before closing <c>B</c>.</p> + port <c>B</c> is tracer, and process <c>C</c> is the port + owner of <c>B</c>. <c>C</c> wants to close <c>B</c> when + <c>A</c> exits. To ensure that the trace is not truncated, + <c>C</c> can call <c>erlang:trace_delivered(A)</c> when + <c>A</c> exits, and wait for message <c>{trace_delivered, A, + <anno>Ref</anno>}</c> before closing <c>B</c>.</p> <p>Failure: <c>badarg</c> if <c><anno>Tracee</anno></c> does not refer to a process (dead or alive) on the same node as the caller of @@ -9217,22 +9477,23 @@ timestamp() -> <func> <name name="trace_info" arity="2"/> - <fsummary>Trace information about a process or function.</fsummary> + <fsummary>Trace information about a process or function.</fsummary> <type name="trace_info_return"/> <type name="trace_info_item_result"/> <type name="trace_info_flag"/> <type name="trace_match_spec"/> <desc> - <p>Returns trace information about a port, process, function or event.</p> + <p>Returns trace information about a port, process, function, or + event.</p> <p><em>To get information about a port or process</em>, - <c><anno>PidPortFuncEvent</anno></c> is to - be a process identifier (pid), port identifier or one of - the atoms <c>new</c>, <c>new_processes</c>, <c>new_ports</c>. - The atom <c>new</c> or <c>new_processes</c> means that the default trace - state for processes to be created is returned. The atom <c>new_ports</c> - means that the default trace state for ports to be created is returned. - </p> - <p>The following <c>Item</c>s are valid for ports and processes:</p> + <c><anno>PidPortFuncEvent</anno></c> is to + be a process identifier (pid), port identifier, or one of + the atoms <c>new</c>, <c>new_processes</c>, or <c>new_ports</c>. The + atom <c>new</c> or <c>new_processes</c> means that the default trace + state for processes to be created is returned. The atom + <c>new_ports</c> means that the default trace state for ports to be + created is returned.</p> + <p>Valid <c>Item</c>s for ports and processes:</p> <taglist> <tag><c>flags</c></tag> <item> @@ -9241,30 +9502,32 @@ timestamp() -> traces are enabled, and one or more of the followings atoms if traces are enabled: <c>send</c>, <c>'receive'</c>, <c>set_on_spawn</c>, <c>call</c>, - <c>return_to</c>, <c>procs</c>, <c>ports</c>, <c>set_on_first_spawn</c>, + <c>return_to</c>, <c>procs</c>, <c>ports</c>, + <c>set_on_first_spawn</c>, <c>set_on_link</c>, <c>running</c>, <c>running_procs</c>, - <c>running_ports</c>, <c>silent</c>, <c>exiting</c> + <c>running_ports</c>, <c>silent</c>, <c>exiting</c>, <c>monotonic_timestamp</c>, <c>strict_monotonic_timestamp</c>, <c>garbage_collection</c>, <c>timestamp</c>, and <c>arity</c>. The order is arbitrary.</p> </item> <tag><c>tracer</c></tag> <item> - <p>Returns the identifier for process, port or a tuple containing + <p>Returns the identifier for process, port, or a tuple containing the tracer module and tracer state tracing this - process. If this process is not being traced, the return + process. If this process is not traced, the return value is <c>[]</c>.</p> </item> </taglist> - <p><em>To get information about a function</em>, <c><anno>PidPortFuncEvent</anno></c> is to + <p><em>To get information about a function</em>, + <c><anno>PidPortFuncEvent</anno></c> is to be the three-element tuple <c>{Module, Function, Arity}</c> or - the atom <c>on_load</c>. No wild cards are allowed. Returns + the atom <c>on_load</c>. No wildcards are allowed. Returns <c>undefined</c> if the function does not exist, or - <c>false</c> if the function is not traced. If <c><anno>PidPortFuncEvent</anno></c> - is <c>on_load</c>, the information returned refers to - the default value for code that will be loaded.</p> - - <p>The following <c>Item</c>s are valid for functions:</p> + <c>false</c> if the function is not traced. + If <c><anno>PidPortFuncEvent</anno></c> + is <c>on_load</c>, the information returned refers to + the default value for code that will be loaded.</p> + <p>Valid <c>Item</c>s for functions:</p> <taglist> <tag><c>traced</c></tag> <item> @@ -9283,11 +9546,12 @@ timestamp() -> </item> <tag><c>meta</c></tag> <item> - <p>Returns the meta-trace tracer process, port or trace module + <p>Returns the meta-trace tracer process, port, or trace module for this function, if it has one. If the function is not meta-traced, the returned value is <c>false</c>. If the function is meta-traced but has once detected that - the tracer process is invalid, the returned value is [].</p> + the tracer process is invalid, the returned value is + <c>[]</c>.</p> </item> <tag><c>meta_match_spec</c></tag> <item> @@ -9300,21 +9564,22 @@ timestamp() -> <item> <p>Returns the call count value for this function or <c>true</c> for the pseudo function <c>on_load</c> if call - count tracing is active. Otherwise <c>false</c> is returned. - See also - <seealso marker="#trace_pattern/3">erlang:trace_pattern/3</seealso>.</p> + count tracing is active. Otherwise <c>false</c> is returned.</p> + <p>See also <seealso marker="#trace_pattern/3"> + <c>erlang:trace_pattern/3</c></seealso>.</p> </item> <tag><c>call_time</c></tag> <item> - <p>Returns the call time values for this function or + <p>Returns the call time values for this function or <c>true</c> for the pseudo function <c>on_load</c> if call - time tracing is active. Otherwise <c>false</c> is returned. - The call time values returned, <c>[{Pid, Count, S, Us}]</c>, - is a list of each process that executed the function - and its specific counters. See also - <seealso marker="#trace_pattern/3">erlang:trace_pattern/3</seealso>.</p> + time tracing is active. Otherwise <c>false</c> is returned. + The call time values returned, <c>[{Pid, Count, S, Us}]</c>, + is a list of each process that executed the function + and its specific counters.</p> + <p>See also + <seealso marker="#trace_pattern/3"> + <c>erlang:trace_pattern/3</c></seealso>.</p> </item> - <tag><c>all</c></tag> <item> <p>Returns a list containing the @@ -9323,80 +9588,84 @@ timestamp() -> is active for this function.</p> </item> </taglist> - <p><em>To get information about an event</em>, <c><anno>PidPortFuncEvent</anno></c> is to + <p><em>To get information about an event</em>, + <c><anno>PidPortFuncEvent</anno></c> is to be one of the atoms <c>send</c> or <c>'receive'</c>.</p> - <p>The only valid <c>Item</c> for events is:</p> + <p>One valid <c>Item</c> for events exists:</p> <taglist> <tag><c>match_spec</c></tag> <item> <p>Returns the match specification for this event, if it has one, or <c>true</c> if no match specification has been - set.</p> + set.</p> </item> </taglist> <p>The return value is <c>{<anno>Item</anno>, Value}</c>, where <c>Value</c> is the requested information as described earlier. - If a pid for a dead process was given, or the name of a + If a pid for a dead process was specified, or the name of a non-existing function, <c>Value</c> is <c>undefined</c>.</p> </desc> </func> <func> <name name="trace_pattern" arity="2" clause_i="1"/> - <fsummary>Sets trace patterns for call, send or 'receive' tracing.</fsummary> + <fsummary>Set trace patterns for call, send, or 'receive' tracing. + </fsummary> <type name="trace_pattern_mfa"/> <type name="trace_match_spec"/> <desc> <p>The same as - <seealso marker="#trace_pattern/3">erlang:trace_pattern(Event, MatchSpec, [])</seealso>, + <seealso marker="#trace_pattern/3"> + <c>erlang:trace_pattern(Event, MatchSpec, [])</c></seealso>, retained for backward compatibility.</p> </desc> </func> <func> <name name="trace_pattern" arity="3" clause_i="1"/> - <fsummary>Sets trace pattern for message sending.</fsummary> + <fsummary>Set trace pattern for message sending.</fsummary> <type name="trace_match_spec"/> <desc> <p>Sets trace pattern for <em>message sending</em>. - Must be combined with - <seealso marker="#trace/3">erlang:trace/3</seealso> + Must be combined with + <seealso marker="#trace/3"><c>erlang:trace/3</c></seealso> to set the <c>send</c> trace flag for one or more processes. - By default all messages, sent from <c>send</c> traced processes, - are traced. Use <c>erlang:trace_pattern/3</c> to limit - traced send events based on the message content, the sender - and/or the receiver.</p> + By default all messages sent from <c>send</c> traced processes + are traced. To limit + traced send events based on the message content, the sender + and/or the receiver, use <c>erlang:trace_pattern/3</c>.</p> <p>Argument <c><anno>MatchSpec</anno></c> can take the following forms:</p> <taglist> <tag><c><anno>MatchSpecList</anno></c></tag> <item> <p>A list of match specifications. The matching is done - on the list <c>[Receiver, Msg]</c>. <c>Receiver</c> - is the process or port identity of the receiver and - <c>Msg</c> is the message term. The pid of the sending - process can be accessed with the guard function - <c>self/0</c>. An empty list is the same as <c>true</c>. - See the users guide section - <seealso marker="erts:match_spec">Match Specifications in Erlang</seealso> - for more information.</p> + on the list <c>[Receiver, Msg]</c>. <c>Receiver</c> + is the process or port identity of the receiver and + <c>Msg</c> is the message term. The pid of the sending + process can be accessed with the guard function + <c>self/0</c>. An empty list is the same as <c>true</c>. + For more information, see section + <seealso marker="erts:match_spec"> + Match Specifications in Erlang</seealso> in the User's Guide.</p> </item> <tag><c>true</c></tag> <item> <p>Enables tracing for all sent messages (from <c>send</c> - traced processes). Any match specification is - removed. <em>This is the default</em>.</p> + traced processes). Any match specification is + removed. <em>This is the default</em>.</p> </item> <tag><c>false</c></tag> <item> <p>Disables tracing for all sent messages. - Any match specification is removed.</p> + Any match specification is removed.</p> </item> </taglist> - <p>Argument <c><anno>FlagList</anno></c> must be <c>[]</c> - for send tracing.</p> - <p>The return value is always <c>1</c>.</p> - <p>Example; only trace messages to a specific process <c>Pid</c>:</p> + <p>Argument <c><anno>FlagList</anno></c> must be <c>[]</c> + for send tracing.</p> + <p>The return value is always <c>1</c>.</p> + <p>Examples:</p> + <p>Only trace messages to a specific process <c>Pid</c>:</p> <pre> > <input>erlang:trace_pattern(send, [{[Pid, '_'],[],[]}], []).</input> 1</pre> @@ -9412,58 +9681,60 @@ timestamp() -> <pre> > <input>erlang:trace_pattern(send, [{['$1', '_'],[{'=/=',{node,'$1'},{node}}],[]}], []).</input> 1</pre> - <note><p>A match specification for <c>send</c> trace can use - all guard and body functions except <c>caller</c>.</p></note> + <note> + <p>A match specification for <c>send</c> trace can use + all guard and body functions except <c>caller</c>.</p> + </note> </desc> </func> <func> <name name="trace_pattern" arity="3" clause_i="2"/> - <fsummary>Sets trace pattern for tracing of message receiving.</fsummary> + <fsummary>Set trace pattern for tracing of message receiving.</fsummary> <type name="trace_match_spec"/> <desc> - <p></p> <p>Sets trace pattern for <em>message receiving</em>. - Must be combined with - <seealso marker="#trace/3">erlang:trace/3</seealso> + Must be combined with + <seealso marker="#trace/3"><c>erlang:trace/3</c></seealso> to set the <c>'receive'</c> trace flag for one or more processes. - By default all messages, received by <c>'receive'</c> traced processes, - are traced. Use <c>erlang:trace_pattern/3</c> to limit - traced receive events based on the message content, the sender - and/or the receiver.</p> + By default all messages received by <c>'receive'</c> traced + processes are traced. To limit + traced receive events based on the message content, the sender + and/or the receiver, use <c>erlang:trace_pattern/3</c>.</p> <p>Argument <c><anno>MatchSpec</anno></c> can take the following forms:</p> <taglist> <tag><c><anno>MatchSpecList</anno></c></tag> <item> <p>A list of match specifications. The matching is done - on the list <c>[Node, Sender, Msg]</c>. <c>Node</c> - is the node name of the sender. <c>Sender</c> is the - process or port identity of the sender, or the atom - <c>undefined</c> if the sender is not known (which may - be the case for remote senders). <c>Msg</c> is the - message term. The pid of the receiving process can be - accessed with the guard function <c>self/0</c>. An empty - list is the same as <c>true</c>. See the users guide section - <seealso marker="erts:match_spec">Match Specifications in Erlang</seealso> - for more information.</p> + on the list <c>[Node, Sender, Msg]</c>. <c>Node</c> + is the node name of the sender. <c>Sender</c> is the + process or port identity of the sender, or the atom + <c>undefined</c> if the sender is not known (which can + be the case for remote senders). <c>Msg</c> is the + message term. The pid of the receiving process can be + accessed with the guard function <c>self/0</c>. An empty + list is the same as <c>true</c>. For more information, see + section <seealso marker="erts:match_spec"> + Match Specifications in Erlang</seealso> in the User's Guide.</p> </item> <tag><c>true</c></tag> <item> <p>Enables tracing for all received messages (to <c>'receive'</c> - traced processes). Any match specification is - removed. <em>This is the default</em>.</p> + traced processes). Any match specification is + removed. <em>This is the default</em>.</p> </item> <tag><c>false</c></tag> <item> <p>Disables tracing for all received messages. - Any match specification is removed.</p> + Any match specification is removed.</p> </item> </taglist> - <p>Argument <c><anno>FlagList</anno></c> must be <c>[]</c> - for receive tracing.</p> - <p>The return value is always <c>1</c>.</p> - <p>Example; only trace messages from a specific process <c>Pid</c>:</p> + <p>Argument <c><anno>FlagList</anno></c> must be <c>[]</c> + for receive tracing.</p> + <p>The return value is always <c>1</c>.</p> + <p>Examples:</p> + <p>Only trace messages from a specific process <c>Pid</c>:</p> <pre> > <input>erlang:trace_pattern('receive', [{['_',Pid, '_'],[],[]}], []).</input> 1</pre> @@ -9475,33 +9746,36 @@ timestamp() -> <pre> > <input>erlang:trace_pattern('receive', [{['$1', '_', '_'],[{'=/=','$1',{node}}],[]}], []).</input> 1</pre> - <note><p>A match specification for <c>'receive'</c> trace can - use all guard and body functions except <c>caller, - is_seq_trace, get_seq_token, set_seq_token, enable_trace, - disable_trace, trace, silent</c> and <c>process_dump</c>.</p></note> + <note> + <p>A match specification for <c>'receive'</c> trace can + use all guard and body functions except <c>caller</c>, + <c>is_seq_trace</c>, <c>get_seq_token</c>, <c>set_seq_token</c>, + <c>enable_trace</c>, <c>disable_trace</c>, <c>trace</c>, + <c>silent</c>, and <c>process_dump</c>.</p> + </note> </desc> </func> <func> <name name="trace_pattern" arity="3" clause_i="3"/> - <fsummary>Sets trace patterns for tracing of function calls.</fsummary> + <fsummary>Set trace patterns for tracing of function calls.</fsummary> <type name="trace_pattern_mfa"/> <type name="trace_match_spec"/> <type name="trace_pattern_flag"/> <desc> <p>Enables or disables <em>call tracing</em> for one or more functions. - Must be combined with - <seealso marker="#trace/3">erlang:trace/3</seealso> + Must be combined with + <seealso marker="#trace/3"><c>erlang:trace/3</c></seealso> to set the <c>call</c> trace flag - for one or more processes.</p> + for one or more processes.</p> <p>Conceptually, call tracing works as follows. Inside - the Erlang Virtual Machine, a set of processes and + the Erlang virtual machine, a set of processes and a set of functions are to be traced. If a traced process calls a traced function, the trace action is taken. Otherwise, nothing happens.</p> <p>To add or remove one or more processes to the set of traced processes, use - <seealso marker="#trace/3">erlang:trace/3</seealso>.</p> + <seealso marker="#trace/3"><c>erlang:trace/3</c></seealso>.</p> <p>To add or remove functions to the set of traced functions, use <c>erlang:trace_pattern/3</c>.</p> <p>The BIF <c>erlang:trace_pattern/3</c> can also add match @@ -9513,10 +9787,10 @@ timestamp() -> fails, the action is not executed.</p> <p>Argument <c><anno>MFA</anno></c> is to be a tuple, such as <c>{Module, Function, Arity}</c>, or the atom <c>on_load</c> - (described in the following). It can be the module, function, + (described below). It can be the module, function, and arity for a function (or a BIF in any module). - The atom <c>'_'</c> can be used as a wild card in any of the - following ways:</p> + The atom <c>'_'</c> can be used as a wildcard in any of the + following ways:</p> <taglist> <tag><c>{Module,Function,'_'}</c></tag> <item> @@ -9533,7 +9807,7 @@ timestamp() -> </item> </taglist> <p>Other combinations, such as <c>{Module,'_',Arity}</c>, are - not allowed. Local functions match wild cards only if + not allowed. Local functions match wildcards only if option <c>local</c> is in <c><anno>FlagList</anno></c>.</p> <p>If argument <c><anno>MFA</anno></c> is the atom <c>on_load</c>, the match specification and flag list are used on all @@ -9549,13 +9823,14 @@ timestamp() -> <tag><c>true</c></tag> <item> <p>Enables tracing for the matching functions. - Any match specification is removed.</p> + Any match specification is removed.</p> </item> <tag><c><anno>MatchSpecList</anno></c></tag> <item> <p>A list of match specifications. An empty list is equivalent to <c>true</c>. For a description of match - specifications, see the User's Guide.</p> + specifications, see section <seealso marker="erts:match_spec"> + Match Specifications in Erlang</seealso> in the User's Guide.</p> </item> <tag><c>restart</c></tag> <item> @@ -9566,7 +9841,7 @@ timestamp() -> </item> <tag><c>pause</c></tag> <item> - <p>For the <c><anno>FlagList</anno></c> options + <p>For the <c><anno>FlagList</anno></c> options <c>call_count</c> and <c>call_time</c>: pauses the existing counters. The behavior is undefined for other <c><anno>FlagList</anno></c> options.</p> @@ -9591,7 +9866,8 @@ timestamp() -> the process, a <c>return_to</c> message is also sent when this function returns to its caller.</p> </item> - <tag><c>meta | {meta, <anno>Pid</anno>} | {meta, <anno>TracerModule</anno>, <anno>TracerState</anno>}</c> + <tag><c>meta | {meta, <anno>Pid</anno>} | + {meta, <anno>TracerModule</anno>, <anno>TracerState</anno>}</c> </tag> <item> <p>Turns on or off meta-tracing for all types of function @@ -9599,7 +9875,7 @@ timestamp() -> the specified functions are called. If no tracer is specified, <c>self()</c> is used as a default tracer process.</p> <p>Meta-tracing traces all processes and does not care - about the process trace flags set by <c>trace/3</c>, + about the process trace flags set by <c>erlang:trace/3</c>, the trace flags are instead fixed to <c>[call, timestamp]</c>.</p> <p>The match specification function <c>{return_trace}</c> @@ -9620,7 +9896,8 @@ timestamp() -> Paused and running counters can be restarted from zero with <c><anno>MatchSpec</anno> == restart</c>.</p> <p>To read the counter value, use - <seealso marker="#trace_info/2">erlang:trace_info/2</seealso>.</p> + <seealso marker="#trace_info/2"> + <c>erlang:trace_info/2</c></seealso>.</p> </item> <tag><c>call_time</c></tag> <item> @@ -9628,17 +9905,18 @@ timestamp() -> (<c><anno>MatchSpec</anno> == false</c>) call time tracing for all types of function calls. For every function, a counter is - incremented when the function is called. + incremented when the function is called. Time spent in the function is accumulated in two other counters, seconds and microseconds. - The counters are stored for each call traced process.</p> + The counters are stored for each call traced process.</p> <p>If call time tracing is started while already running, - the count and time is restarted from zero. To pause + the count and time restart from zero. To pause running counters, use <c><anno>MatchSpec</anno> == pause</c>. Paused and running counters can be restarted from zero with <c><anno>MatchSpec</anno> == restart</c>.</p> <p>To read the counter value, use - <seealso marker="#trace_info/2">erlang:trace_info/2</seealso>.</p> + <seealso marker="#trace_info/2"> + <c>erlang:trace_info/2</c></seealso>.</p> </item> </taglist> <p>The options <c>global</c> and <c>local</c> are mutually @@ -9653,12 +9931,12 @@ timestamp() -> <p>When disabling trace, the option must match the type of trace set on the function. That is, local tracing must be disabled with option <c>local</c> and global tracing with - option <c>global</c> (or no option), and so forth.</p> + option <c>global</c> (or no option), and so on.</p> <p>Part of a match specification list cannot be changed directly. If a function has a match specification, it can be replaced with a new one. To change an existing match specification, use the BIF - <seealso marker="#trace_info/2">erlang:trace_info/2</seealso> + <seealso marker="#trace_info/2"><c>erlang:trace_info/2</c></seealso> to retrieve the existing match specification.</p> <p>Returns the number of functions matching argument <c><anno>MFA</anno></c>. This is zero if none matched.</p> @@ -9667,7 +9945,7 @@ timestamp() -> <func> <name name="trunc" arity="1"/> - <fsummary>Returns an integer by truncating a number</fsummary> + <fsummary>Return an integer by truncating a number.</fsummary> <desc> <p>Returns an integer by truncating <c><anno>Number</anno></c>, for example:</p> @@ -9680,7 +9958,7 @@ timestamp() -> <func> <name name="tuple_size" arity="1"/> - <fsummary>Returns the size of a tuple.</fsummary> + <fsummary>Return the size of a tuple.</fsummary> <desc> <p>Returns an integer that is the number of elements in <c><anno>Tuple</anno></c>, for example:</p> @@ -9693,11 +9971,11 @@ timestamp() -> <func> <name name="tuple_to_list" arity="1"/> - <fsummary>Converts a tuple to a list.</fsummary> + <fsummary>Convert a tuple to a list.</fsummary> <desc> <p>Returns a list corresponding to <c><anno>Tuple</anno></c>. - <c><anno>Tuple</anno></c> can contain any Erlang terms.</p> - <p>Example:</p> + <c><anno>Tuple</anno></c> can contain any Erlang terms. + Example:</p> <pre> > <input>tuple_to_list({share, {'Ericsson_B', 163}}).</input> [share,{'Ericsson_B',163}]</pre> @@ -9705,16 +9983,111 @@ timestamp() -> </func> <func> + <name name="unique_integer" arity="0"/> + <fsummary>Get a unique integer value.</fsummary> + <desc> + <p>Generates and returns an + <seealso marker="doc/efficiency_guide:advanced#unique_integers"> + integer unique on current runtime system instance</seealso>. + The same as calling + <seealso marker="#unique_integer/1"> + <c>erlang:unique_integer([])</c></seealso>.</p> + </desc> + </func> + + <func> + <name name="unique_integer" arity="1"/> + <fsummary>Get a unique integer value.</fsummary> + <desc> + <p>Generates and returns an + <seealso marker="doc/efficiency_guide:advanced#unique_integers"> + integer unique on current runtime system + instance</seealso>. The integer is unique in the + sense that this BIF, using the same set of + modifiers, does not return the same integer more + than once on the current runtime system instance. + Each integer value can of course be constructed + by other means.</p> + <p>By default, when <c>[]</c> is passed as + <c><anno>ModifierList</anno></c>, both negative and + positive integers can be returned. This + to use the range of integers that do + not need heap memory allocation as much as possible. + By default the returned integers are also only + guaranteed to be unique, that is, any returned integer + can be smaller or larger than previously + returned integers.</p> + <p><c><anno>Modifier</anno></c>s:</p> + <taglist> + <tag>positive</tag> + <item> + <p>Returns only positive integers.</p> + <p>Notice that by passing the <c>positive</c> modifier + you will get heap allocated integers (bignums) quicker.</p> + </item> + <tag>monotonic</tag> + <item> + <p>Returns <seealso + marker="time_correction#Strictly_Monotonically_Increasing"> + strictly monotonically increasing</seealso> integers + corresponding to creation time. That is, the integer + returned is always larger than previously + returned integers on the current runtime system + instance.</p> + <p>These values can be used to determine order between events + on the runtime system instance. That is, if both + <c>X = erlang:unique_integer([monotonic])</c> and + <c>Y = erlang:unique_integer([monotonic])</c> are + executed by different processes (or the same + process) on the same runtime system instance and + <c>X < Y</c>, we know that <c>X</c> was created + before <c>Y</c>.</p> + <warning> + <p>Strictly monotonically increasing values + are inherently quite expensive to generate and scales + poorly. This is because the values need to be synchronized + between CPU cores. That is, do not pass the <c>monotonic</c> + modifier unless you really need strictly monotonically + increasing values.</p> + </warning> + </item> + </taglist> + <p>All valid <c><anno>Modifier</anno></c>s + can be combined. Repeated (valid) + <c><anno>Modifier</anno></c>s in the <c>ModifierList</c> + are ignored.</p> + <note> + <p>The set of integers returned by + <c>erlang:unique_integer/1</c> using different sets of + <c><anno>Modifier</anno></c>s <em>will overlap</em>. + For example, by calling <c>unique_integer([monotonic])</c>, + and <c>unique_integer([positive, monotonic])</c> + repeatedly, you will eventually see some integers that are + returned by both calls.</p> + </note> + <p>Failures:</p> + <taglist> + <tag><c>badarg</c></tag> + <item>if <c><anno>ModifierList</anno></c> is not a + proper list.</item> + <tag><c>badarg</c></tag> + <item>if <c><anno>Modifier</anno></c> is not a + valid modifier.</item> + </taglist> + </desc> + </func> + + <func> <name name="universaltime" arity="0"/> - <fsummary>Current date and time according to Universal Time Coordinated (UTC).</fsummary> + <fsummary>Current date and time according to Universal Time Coordinated + (UTC).</fsummary> <desc> <p>Returns the current date and time according to Universal Time Coordinated (UTC) in the form <c>{{Year, Month, Day}, {Hour, Minute, Second}}</c> if supported by the underlying OS. Otherwise <c>erlang:universaltime()</c> is equivalent to - <c>erlang:localtime()</c>.</p> - <p>Example:</p> + <c>erlang:localtime()</c>. Example:</p> <pre> > <input>erlang:universaltime().</input> {{1996,11,6},{14,18,43}}</pre> @@ -9723,15 +10096,15 @@ timestamp() -> <func> <name name="universaltime_to_localtime" arity="1"/> - <fsummary>Converts from Universal Time Coordinated (UTC) to local date and time.</fsummary> + <fsummary>Convert from Universal Time Coordinated (UTC) to local date + and time.</fsummary> <desc> <p>Converts Universal Time Coordinated (UTC) date and time to local date and time in the form <c>{{Year, Month, Day}, {Hour, Minute, Second}}</c> if supported by the underlying OS. Otherwise no conversion is done, and - <c><anno>Universaltime</anno></c> is returned.</p> - <p>Example:</p> + <c><anno>Universaltime</anno></c> is returned. Example:</p> <pre> > <input>erlang:universaltime_to_localtime({{1996,11,6},{14,18,43}}).</input> {{1996,11,7},{15,18,43}}</pre> @@ -9741,102 +10114,8 @@ timestamp() -> </func> <func> - <name name="unique_integer" arity="0"/> - <fsummary>Get a unique integer value</fsummary> - <desc> - <p>Generates and returns an - <seealso marker="doc/efficiency_guide:advanced#unique_integers">integer - unique on current runtime system instance</seealso>. The same as calling - <seealso marker="#unique_integer/1"><c>erlang:unique_integer([])</c></seealso>.</p> - </desc> - </func> - <func> - <name name="unique_integer" arity="1"/> - <fsummary>Get a unique integer value</fsummary> - <desc> - <p>Generates and returns an - <seealso marker="doc/efficiency_guide:advanced#unique_integers">integer - unique on current runtime system - instance</seealso>. The integer is unique in the - sense that this BIF, using the same set of - modifiers, will not return the same integer more - than once on the current runtime system instance. - Each integer value can of course be constructed - by other means.</p> - - <p>By default, when <c>[]</c> is passed as - <c><anno>ModifierList</anno></c>, both negative and - positive integers can be returned. This in order - to utilize the range of integers that do - not need heap memory allocation as much as possible. - By default the returned integers are also only - guaranteed to be unique, that is, any returned integer - can be smaller or larger than previously - returned integers.</p> - - <p>Valid <c><anno>Modifier</anno></c>s:</p> - <taglist> - - <tag>positive</tag> - <item><p>Return only positive integers.</p> - <p>Note that by passing the <c>positive</c> modifier - you will get heap allocated integers (bignums) - quicker.</p> - </item> - - <tag>monotonic</tag> - <item><p>Return - <seealso marker="time_correction#Strictly_Monotonically_Increasing">strictly - monotonically increasing</seealso> integers - corresponding to creation time. That is, the integer - returned will always be larger than previously - returned integers on the current runtime system - instance.</p> - <p>These values can be used to determine order between events - on the runtime system instance. That is, if both - <c>X = erlang:unique_integer([monotonic])</c> and - <c>Y = erlang:unique_integer([monotonic])</c> are - executed by different processes (or the same - process) on the same runtime system instance and - <c>X < Y</c> we know that <c>X</c> was created - before <c>Y</c>.</p> - <warning><p>Strictly monotonically increasing values - are inherently quite expensive to generate and scales - poorly. This is because the values need to be - synchronized between cpu cores. That is, do not pass the <c>monotonic</c> - modifier unless you really need strictly monotonically - increasing values.</p></warning> - </item> - - </taglist> - - <p>All valid <c><anno>Modifier</anno></c>s - can be combined. Repeated (valid) - <c><anno>Modifier</anno></c>s in the <c>ModifierList</c> - are ignored.</p> - - <note><p>Note that the set of integers returned by - <c>unique_integer/1</c> using different sets of - <c><anno>Modifier</anno></c>s <em>will overlap</em>. - For example, by calling <c>unique_integer([monotonic])</c>, - and <c>unique_integer([positive, monotonic])</c> - repeatedly, you will eventually see some integers being - returned by both calls.</p></note> - - <p>Failures:</p> - <taglist> - <tag><c>badarg</c></tag> - <item>if <c><anno>ModifierList</anno></c> is not a - proper list.</item> - <tag><c>badarg</c></tag> - <item>if <c><anno>Modifier</anno></c> is not a - valid modifier.</item> - </taglist> - </desc> - </func> - <func> <name name="unlink" arity="1"/> - <fsummary>Removes a link to another process or port.</fsummary> + <fsummary>Remove a link to another process or port.</fsummary> <desc> <p>Removes the link, if there is one, between the calling process and the process or port referred to by @@ -9851,8 +10130,8 @@ timestamp() -> in the future (unless the link is setup again). If the caller is trapping exits, an <c>{'EXIT', <anno>Id</anno>, _}</c> message from the link - can have been placed in the caller's message queue before - the call.</p> + can have been placed in the caller's message queue before + the call.</p> <p>Notice that the <c>{'EXIT', <anno>Id</anno>, _}</c> message can be the result of the link, but can also be the result of <c>Id</c> @@ -9860,16 +10139,16 @@ timestamp() -> appropriate to clean up the message queue when trapping exits after the call to <c>unlink(<anno>Id</anno>)</c>, as follows:</p> <code type="none"> - unlink(Id), - receive - {'EXIT', Id, _} -> - true - after 0 -> - true - end</code> +unlink(Id), +receive + {'EXIT', Id, _} -> + true +after 0 -> + true +end</code> <note> - <p>Prior to OTP release R11B (ERTS version 5.5) <c>unlink/1</c> - behaved completely asynchronously, i.e., the link was active + <p>Before Erlang/OTP R11B (ERTS 5.5) <c>unlink/1</c> + behaved completely asynchronously, that is, the link was active until the "unlink signal" reached the linked entity. This had an undesirable effect, as you could never know when you were guaranteed <em>not</em> to be effected by the link.</p> @@ -9882,7 +10161,7 @@ timestamp() -> <func> <name name="unregister" arity="1"/> - <fsummary>Removes the registered name for a process (or port).</fsummary> + <fsummary>Remove the registered name for a process (or port).</fsummary> <desc> <p>Removes the registered name <c><anno>RegName</anno></c> associated with a @@ -9898,12 +10177,12 @@ true</pre> <func> <name name="whereis" arity="1"/> - <fsummary>Gets the pid (or port) with a given registered name.</fsummary> + <fsummary>Get the pid (or port) with a specified registered name. + </fsummary> <desc> <p>Returns the process identifier or port identifier with the registered name <c>RegName</c>. Returns <c>undefined</c> - if the name is not registered.</p> - <p>Example:</p> + if the name is not registered. Example:</p> <pre> > <input>whereis(db).</input> <0.43.0></pre> @@ -9912,17 +10191,19 @@ true</pre> <func> <name name="yield" arity="0"/> - <fsummary>Lets other processes get a chance to execute.</fsummary> + <fsummary>Let other processes get a chance to execute.</fsummary> <desc> <p>Voluntarily lets other processes (if any) get a chance to - execute. Using <c>erlang:yield()</c> is similar to + execute. Using this function is similar to <c>receive after 1 -> ok end</c>, except that <c>yield()</c> is faster.</p> - <warning><p>There is seldom or never any need to use this BIF, - especially in the SMP emulator, as other processes have a - chance to run in another scheduler thread anyway. - Using this BIF without a thorough grasp of how the scheduler - works can cause performance degradation.</p></warning> + <warning> + <p>There is seldom or never any need to use this BIF, + especially in the SMP emulator, as other processes have a + chance to run in another scheduler thread anyway. + Using this BIF without a thorough grasp of how the scheduler + works can cause performance degradation.</p> + </warning> </desc> </func> </funcs> |