erlang(3)



erlang(3erl)               Erlang Module Definition               erlang(3erl)

NAME
       erlang - The Erlang BIFs.

DESCRIPTION
       By convention, most Built-In Functions (BIFs) are included in this mod-
       ule. Some of the BIFs are viewed more or less as  part  of  the  Erlang
       programming  language  and are auto-imported. Thus, it is not necessary
       to specify the module name. For example, the calls atom_to_list(erlang)
       and erlang:atom_to_list(erlang) are identical.

       Auto-imported  BIFs  are listed without module prefix. BIFs listed with
       module prefix are not auto-imported.

       BIFs can fail for various reasons. All BIFs fail with reason badarg  if
       they  are called with arguments of an incorrect type. The other reasons
       are described in the description of each individual BIF.

       Some BIFs can be used in guard tests and are marked  with  "Allowed  in
       guard tests".

DATA TYPES
       ext_binary() = binary()

              A  binary data object, structured according to the Erlang exter-
              nal term format.

       ext_iovec() = iovec()

              A term of type iovec(), structured according to the  Erlang  ex-
              ternal term format.

       iovec() = [binary()]

              A list of binaries. This datatype is useful to use together with
              enif_inspect_iovec.

       message_queue_data() = off_heap | on_heap

              See process_flag(message_queue_data, MQD).

       timestamp() =
           {MegaSecs :: integer() >= 0,
            Secs :: integer() >= 0,
            MicroSecs :: integer() >= 0}

              See erlang:timestamp/0.

       time_unit() =
           integer() >= 1 |
           second | millisecond | microsecond | nanosecond | native |
           perf_counter |
           deprecated_time_unit()

              Supported time unit representations:

                PartsPerSecond :: integer() >= 1:
                  Time unit expressed in parts per second. That is,  the  time
                  unit equals 1/PartsPerSecond second.

                second:
                  Symbolic  representation of the time unit represented by the
                  integer 1.

                millisecond:
                  Symbolic representation of the time unit represented by  the
                  integer 1000.

                microsecond:
                  Symbolic  representation of the time unit represented by the
                  integer 1000000.

                nanosecond:
                  Symbolic representation of the time unit represented by  the
                  integer 1000000000.

                native:
                  Symbolic  representation of the native time unit used by the
                  Erlang runtime system.

                  The native 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 native time unit of the new runtime
                  system instance can differ from the native time unit of  the
                  old runtime system instance.

                  One  can  get  an  approximation  of the native time unit by
                  calling erlang:convert_time_unit(1, second, native). The re-
                  sult  equals  the number of whole native time units per sec-
                  ond. If the number of native time units per second does  not
                  add up to a whole number, the result is rounded downwards.

            Note:
                The  value  of  the native time unit gives you more or less no
                information about the quality of time values. It sets a  limit
                for the  resolution and for the  precision of time values, but
                it gives no information about the  accuracy  of  time  values.
                The  resolution  of the native time unit and the resolution of
                time values can differ significantly.

                perf_counter:
                  Symbolic representation of the performance counter time unit
                  used by the Erlang runtime system.

                  The  perf_counter  time unit behaves much in the same way as
                  the native time unit. That is, it can differ between runtime
                  restarts.    To    get    values    of   this   type,   call
                  os:perf_counter/0.

                deprecated_time_unit():
                  Deprecated symbolic representations kept for  backwards-com-
                  patibility.

              The time_unit/0 type can be extended. To convert time values be-
              tween time units, use erlang:convert_time_unit/3.

       deprecated_time_unit() =
           seconds | milli_seconds | micro_seconds | nano_seconds

              The time_unit() type also consist of  the  following  deprecated
              symbolic time units:

                seconds:
                  Same as second.

                milli_seconds:
                  Same as millisecond.

                micro_seconds:
                  Same as microsecond.

                nano_seconds:
                  Same as nanosecond.

       dist_handle()

              An opaque handle identifing a distribution channel.

       nif_resource()

              An opaque handle identifing a NIF resource object .

       spawn_opt_option() =
           link | monitor |
           {priority, Level :: priority_level()} |
           {fullsweep_after, Number :: integer() >= 0} |
           {min_heap_size, Size :: integer() >= 0} |
           {min_bin_vheap_size, VSize :: integer() >= 0} |
           {max_heap_size, Size :: max_heap_size()} |
           {message_queue_data, MQD :: message_queue_data()}

              Options for spawn_opt().

       priority_level() = low | normal | high | max

              Process priority level. For more info see process_flag(priority,
              Level)

       max_heap_size() =
           integer() >= 0 |
           #{size => integer() >= 0,
             kill => boolean(),
             error_logger => boolean()}

              Process  max  heap  size  configuration.  For  more   info   see
              process_flag(max_heap_size, MaxHeapSize)

       message_queue_data() = off_heap | on_heap

              Process  message  queue  data  configuration.  For more info see
              process_flag(message_queue_data, MQD)

EXPORTS
       abs(Float) -> float()

       abs(Int) -> integer() >= 0

              Types:

                 Int = integer()

              Returns an integer or float that is  the  arithmetical  absolute
              value of Float or Int, for example:

              > abs(-3.33).
              3.33
              > abs(-3).
              3

              Allowed in guard tests.

       erlang:adler32(Data) -> integer() >= 0

              Types:

                 Data = iodata()

              Computes and returns the adler32 checksum for Data.

       erlang:adler32(OldAdler, Data) -> integer() >= 0

              Types:

                 OldAdler = integer() >= 0
                 Data = iodata()

              Continues computing the adler32 checksum by combining the previ-
              ous checksum, OldAdler, with the checksum of Data.

              The following code:

              X = erlang:adler32(Data1),
              Y = erlang:adler32(X,Data2).

              assigns the same value to Y as this:

              Y = erlang:adler32([Data1,Data2]).

       erlang:adler32_combine(FirstAdler, SecondAdler, SecondSize) ->
                                 integer() >= 0

              Types:

                 FirstAdler = SecondAdler = SecondSize = integer() >= 0

              Combines two previously computed adler32 checksums. This  compu-
              tation  requires  the  size  of  the  data object for the second
              checksum to be known.

              The following code:

              Y = erlang:adler32(Data1),
              Z = erlang:adler32(Y,Data2).

              assigns the same value to Z as this:

              X = erlang:adler32(Data1),
              Y = erlang:adler32(Data2),
              Z = erlang:adler32_combine(X,Y,iolist_size(Data2)).

       erlang:append_element(Tuple1, Term) -> Tuple2

              Types:

                 Tuple1 = Tuple2 = tuple()
                 Term = term()

              Returns a new tuple that has one element more than  Tuple1,  and
              contains the elements in Tuple1 followed by Term as the last el-
              ement.    Semantically    equivalent    to     list_to_tuple(tu-
              ple_to_list(Tuple1) ++ [Term]), but much faster. Example:

              > erlang:append_element({one, two}, three).
              {one,two,three}

       apply(Fun, Args) -> term()

              Types:

                 Fun = function()
                 Args = [term()]

              Calls a fun, passing the elements in Args as arguments.

              If  the number of elements in the arguments are known at compile
              time, the call is better written as Fun(Arg1, Arg2, ... ArgN).

          Warning:
              Earlier, Fun could also  be  specified  as  {Module,  Function},
              equivalent  to apply(Module, Function, Args). This use is depre-
              cated and will stop working in a future release.

       apply(Module, Function, Args) -> term()

              Types:

                 Module = module()
                 Function = atom()
                 Args = [term()]

              Returns the result of applying Function in Module to  Args.  The
              applied  function must be exported from Module. The arity of the
              function is the length of Args. Example:

              > apply(lists, reverse, [[a, b, c]]).
              [c,b,a]
              > apply(erlang, atom_to_list, ['Erlang']).
              "Erlang"

              If the number of arguments are known at compile time,  the  call
              is better written as Module:Function(Arg1, Arg2, ..., ArgN).

              Failure: error_handler:undefined_function/3 is called if the ap-
              plied function is not exported. The error handler can  be  rede-
              fined (see process_flag/2). If error_handler is undefined, or if
              the user has redefined the default error_handler so the replace-
              ment  module  is undefined, an error with reason undef is gener-
              ated.

       atom_to_binary(Atom) -> binary()

              Types:

                 Atom = atom()

              The same as atom_to_binary(Atom, utf8).

       atom_to_binary(Atom, Encoding) -> binary()

              Types:

                 Atom = atom()
                 Encoding = latin1 | unicode | utf8

              Returns a binary corresponding to  the  text  representation  of
              Atom.  If Encoding is latin1, one byte exists for each character
              in the text representation. If Encoding is utf8 or unicode,  the
              characters  are encoded using UTF-8 where characters may require
              multiple bytes.

          Note:
              As from Erlang/OTP 20, atoms can contain any  Unicode  character
              and  atom_to_binary(Atom, latin1) may fail if the text represen-
              tation for Atom contains a Unicode character > 255.

              Example:

              > atom_to_binary('Erlang', latin1).
              <<"Erlang">>

       atom_to_list(Atom) -> string()

              Types:

                 Atom = atom()

              Returns a string corresponding to  the  text  representation  of
              Atom, for example:

              > atom_to_list('Erlang').
              "Erlang"

       binary_part(Subject, PosLen) -> binary()

              Types:

                 Subject = binary()
                 PosLen = {Start :: integer() >= 0, Length :: integer()}

              Extracts the part of the binary described by PosLen.

              Negative length can be used to extract bytes at the end of a bi-
              nary, for example:

              1> Bin = <<1,2,3,4,5,6,7,8,9,10>>.
              2> binary_part(Bin,{byte_size(Bin), -5}).
              <<6,7,8,9,10>>

              Failure: badarg if PosLen in any way references outside the  bi-
              nary.

              Start is zero-based, that is:

              1> Bin = <<1,2,3>>
              2> binary_part(Bin,{0,2}).
              <<1,2>>

              For details about the PosLen semantics, see binary(3erl).

              Allowed in guard tests.

       binary_part(Subject, Start, Length) -> binary()

              Types:

                 Subject = binary()
                 Start = integer() >= 0
                 Length = integer()

              The same as binary_part(Subject, {Start, Length}).

              Allowed in guard tests.

       binary_to_atom(Binary) -> atom()

              Types:

                 Binary = binary()

              The same as binary_to_atom(Binary, utf8).

       binary_to_atom(Binary, Encoding) -> atom()

              Types:

                 Binary = binary()
                 Encoding = latin1 | unicode | utf8

              Returns  the atom whose text representation is Binary. If Encod-
              ing is utf8 or unicode, the binary must contain valid UTF-8  se-
              quences.

          Note:
              As  from  Erlang/OTP 20, binary_to_atom(Binary, utf8) is capable
              of encoding any Unicode character. Earlier versions  would  fail
              if  the  binary contained Unicode characters > 255. For more in-
              formation about Unicode support in atoms, see the note on  UTF-8
              encoded  atoms  in  section "External Term Format" in the User's
              Guide.

              Examples:

              > binary_to_atom(<<"Erlang">>, latin1).
              'Erlang'
              > binary_to_atom(<<1024/utf8>>, utf8).

       binary_to_existing_atom(Binary) -> atom()

              Types:

                 Binary = binary()

              The same as binary_to_existing_atom (Binary, utf8).

       binary_to_existing_atom(Binary, Encoding) -> atom()

              Types:

                 Binary = binary()
                 Encoding = latin1 | unicode | utf8

              As binary_to_atom/2, but the atom must exist.

              Failure: badarg if the atom does not exist.

          Note:
              Note that the compiler may optimize away atoms. For example, the
              compiler will rewrite atom_to_list(some_atom) to "some_atom". If
              that expression is the only mention of the atom some_atom in the
              containing  module, the atom will not be created when the module
              is  loaded,  and   a   subsequent   call   to   binary_to_exist-
              ing_atom(<<"some_atom">>, utf8) will fail.

       binary_to_float(Binary) -> float()

              Types:

                 Binary = binary()

              Returns the float whose text representation is Binary, for exam-
              ple:

              > binary_to_float(<<"2.2017764e+0">>).
              2.2017764

              Failure: badarg if Binary contains a  bad  representation  of  a
              float.

       binary_to_integer(Binary) -> integer()

              Types:

                 Binary = binary()

              Returns  an integer whose text representation is Binary, for ex-
              ample:

              > binary_to_integer(<<"123">>).
              123

              Failure: badarg if Binary contains a bad  representation  of  an
              integer.

       binary_to_integer(Binary, Base) -> integer()

              Types:

                 Binary = binary()
                 Base = 2..36

              Returns an integer whose text representation in base Base is Bi-
              nary, for example:

              > binary_to_integer(<<"3FF">>, 16).
              1023

              Failure: badarg if Binary contains a bad  representation  of  an
              integer.

       binary_to_list(Binary) -> [byte()]

              Types:

                 Binary = binary()

              Returns a list of integers corresponding to the bytes of Binary.

       binary_to_list(Binary, Start, Stop) -> [byte()]

              Types:

                 Binary = binary()
                 Start = Stop = integer() >= 1
                   1..byte_size(Binary)

              As  binary_to_list/1, but returns a list of integers correspond-
              ing to the bytes from position Start to position Stop in Binary.
              The positions in the binary are numbered starting from 1.

          Note:
              The  one-based  indexing  for  binaries used by this function is
              deprecated. New code is to use  binary:bin_to_list/3  in  STDLIB
              instead.  All  functions in module binary consistently use zero-
              based indexing.

       binary_to_term(Binary) -> term()

              Types:

                 Binary = ext_binary()

              Returns an Erlang term that is the result of decoding binary ob-
              ject  Binary, which must be encoded according to the  Erlang ex-
              ternal term format.

              > Bin = term_to_binary(hello).
              <<131,100,0,5,104,101,108,108,111>>
              > hello = binary_to_term(Bin).
              hello

          Warning:
              When decoding binaries from untrusted  sources,  consider  using
              binary_to_term/2 to prevent Denial of Service attacks.

              See also term_to_binary/1 and binary_to_term/2.

       binary_to_term(Binary, Opts) -> term() | {term(), Used}

              Types:

                 Binary = ext_binary()
                 Opt = safe | used
                 Opts = [Opt]
                 Used = integer() >= 1

              As binary_to_term/1, but takes these options:

                safe:
                  Use  this  option  when receiving binaries from an untrusted
                  source.

                  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 badarg error.

                  This prevents creation of new atoms  directly,  creation  of
                  new atoms indirectly (as they are embedded in certain struc-
                  tures, 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.

                > binary_to_term(<<131,100,0,5,"hello">>, [safe]).
                ** exception error: bad argument
                > hello.
                hello
                > binary_to_term(<<131,100,0,5,"hello">>, [safe]).
                hello

                used:
                  Changes  the  return value to {Term, Used} where Used is the
                  number of bytes actually read from Binary.

                > Input = <<131,100,0,5,"hello","world">>.
                <<131,100,0,5,104,101,108,108,111,119,111,114,108,100>>
                > {Term, Used} = binary_to_term(Input, [used]).
                {hello, 9}
                > split_binary(Input, Used).
                {<<131,100,0,5,104,101,108,108,111>>, <<"world">>}

              Failure: badarg if safe is specified and unsafe data is decoded.

              See also term_to_binary/1, binary_to_term/1, and  list_to_exist-
              ing_atom/1.

       bit_size(Bitstring) -> integer() >= 0

              Types:

                 Bitstring = bitstring()

              Returns  an  integer  that is the size in bits of Bitstring, for
              example:

              > bit_size(<<433:16,3:3>>).
              19
              > bit_size(<<1,2,3>>).
              24

              Allowed in guard tests.

       bitstring_to_list(Bitstring) -> [byte() | bitstring()]

              Types:

                 Bitstring = bitstring()

              Returns a list of integers corresponding to the  bytes  of  Bit-
              string.  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.

       erlang:bump_reductions(Reductions) -> true

              Types:

                 Reductions = integer() >= 1

              This  implementation-dependent function increments the reduction
              counter for the calling process. In the Beam emulator,  the  re-
              duction 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 re-
              ductions in Erlang/OTP R12B).

          Warning:
              This BIF can be removed in a future version of the Beam  machine
              without prior warning. It is unlikely to be implemented in other
              Erlang implementations.

       byte_size(Bitstring) -> integer() >= 0

              Types:

                 Bitstring = bitstring()

              Returns an integer that is the number of bytes needed to contain
              Bitstring.  That  is,  if the number of bits in Bitstring is not
              divisible by 8, the resulting number of bytes is rounded up. Ex-
              amples:

              > byte_size(<<433:16,3:3>>).
              3
              > byte_size(<<1,2,3>>).
              3

              Allowed in guard tests.

       erlang:cancel_timer(TimerRef) -> Result

              Types:

                 TimerRef = reference()
                 Time = integer() >= 0
                 Result = Time | false

              Cancels  a timer. The same as calling erlang:cancel_timer(Timer-
              Ref, []).

       erlang:cancel_timer(TimerRef, Options) -> Result | ok

              Types:

                 TimerRef = reference()
                 Async = Info = boolean()
                 Option = {async, Async} | {info, Info}
                 Options = [Option]
                 Time = integer() >= 0
                 Result = Time | false

              Cancels a timer that has been created by  erlang:start_timer  or
              erlang:send_after.  TimerRef  identifies  the timer, and was re-
              turned by the BIF that created the timer.

              Options:

                {async, Async}:
                  Asynchronous request for  cancellation.  Async  defaults  to
                  false,  which  causes  the cancellation to be performed syn-
                  chronously. When Async is set to true, the cancel  operation
                  is  performed  asynchronously. That is, cancel_timer() sends
                  an asynchronous request for cancellation to the  timer  ser-
                  vice that manages the timer, and then returns ok.

                {info, Info}:
                  Requests  information  about the Result of the cancellation.
                  Info defaults to true, which means the Result is given. When
                  Info is set to false, no information about the result of the
                  cancellation is given.

                  * When Async is false: if Info is true, the  Result  is  re-
                    turned by erlang:cancel_timer(). otherwise ok is returned.

                  * When Async is true: if Info is true, a message on the form
                    {cancel_timer, TimerRef, Result} is sent to the caller  of
                    erlang:cancel_timer()  when the cancellation operation has
                    been performed, otherwise no message is sent.

              More Options may be added in the future.

              If Result is an integer, it represents the time in  milliseconds
              left until the canceled timer would have expired.

              If  Result is false, a timer corresponding to TimerRef could not
              be found. This can be either because the timer had expired,  al-
              ready  had been canceled, or because TimerRef 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.

          Note:
              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 wait-
              ing for the result of this operation, or is  not  interested  in
              the  result  of  the  operation,  you want to use option {async,
              true}. If using  option  {async,  false},  the  calling  process
              blocks until the operation has been performed.

              See  also  erlang:send_after/4,  erlang:start_timer/4,  and  er-
              lang:read_timer/2.

       ceil(Number) -> integer()

              Types:

                 Number = number()

              Returns the smallest integer not less than Number. For example:

              > ceil(5.5).
              6

              Allowed in guard tests.

       check_old_code(Module) -> boolean()

              Types:

                 Module = module()

              Returns true if Module has old code, otherwise false.

              See also code(3erl).

       check_process_code(Pid, Module) -> CheckResult

              Types:

                 Pid = pid()
                 Module = module()
                 CheckResult = boolean()

              The same as check_process_code(Pid, Module, []).

       check_process_code(Pid, Module, OptionList) -> CheckResult | async

              Types:

                 Pid = pid()
                 Module = module()
                 RequestId = term()
                 Option = {async, RequestId} | {allow_gc, boolean()}
                 OptionList = [Option]
                 CheckResult = boolean() | aborted

              Checks if the node local process identified by Pid executes  old
              code for Module.

              Options:

                {allow_gc, boolean()}:
                  Determines  if garbage collection is allowed when performing
                  the operation. If {allow_gc, false} is passed, and a garbage
                  collection  is  needed to determine the result of the opera-
                  tion, the operation is aborted (see information on  CheckRe-
                  sult  below).  The  default  is to allow garbage collection,
                  that is, {allow_gc, true}.

                {async, RequestId}:
                  The function check_process_code/3 returns  the  value  async
                  immediately  after  the  request has been sent. When the re-
                  quest has been processed, the process that called this func-
                  tion  is  passed  a message on the form {check_process_code,
                  RequestId, CheckResult}.

              If Pid equals self(), and no async option has been  passed,  the
              operation  is performed at once. Otherwise a request for the op-
              eration is sent to the process identified by Pid, and is handled
              when appropriate. If no async option has been passed, the caller
              blocks until CheckResult is available and can be returned.

              CheckResult informs about the result of the request as follows:

                true:
                  The process identified by Pid executes old code for  Module.
                  That  is,  the current call of the process executes old code
                  for this module, or the process has references to  old  code
                  for  this  module,  or the process contains funs that refer-
                  ences old code for this module.

                false:
                  The process identified by Pid does not execute old code  for
                  Module.

                aborted:
                  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 {allow_gc, false}.

          Note:
              Up  until  ERTS  version  8.*,  the check process code operation
              checks for all types of references to the old code. That is, di-
              rect  references  (e.g.  return addresses on the process stack),
              indirect references (funs in process context), and references to
              literals in the code.

              As  of  ERTS  version 9.0, the check process code operation only
              checks for direct references to the  code.  Indirect  references
              via  funs will be ignored. If such funs exist and are used after
              a purge of the old code, an exception will be raised upon  usage
              (same  as the case when the fun 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
              building OTP, and will automatically be enabled if dirty  sched-
              uler support is enabled.

              See also code(3erl).

              Failures:

                badarg:
                  If Pid is not a node local process identifier.

                badarg:
                  If Module is not an atom.

                badarg:
                  If OptionList is an invalid list of options.

       erlang:convert_time_unit(Time, FromUnit, ToUnit) -> ConvertedTime

              Types:

                 Time = ConvertedTime = integer()
                 FromUnit = ToUnit = time_unit()

              Converts the Time value of time unit FromUnit to the correspond-
              ing ConvertedTime value of  time  unit  ToUnit.  The  result  is
              rounded using the floor function.

          Warning:
              You can lose accuracy and precision when converting between time
              units. To minimize such loss, collect all data  at  native  time
              unit and do the conversion on the end result.

       erlang:crc32(Data) -> integer() >= 0

              Types:

                 Data = iodata()

              Computes  and  returns the crc32 (IEEE 802.3 style) checksum for
              Data.

       erlang:crc32(OldCrc, Data) -> integer() >= 0

              Types:

                 OldCrc = integer() >= 0
                 Data = iodata()

              Continues computing the crc32 checksum by combining the previous
              checksum, OldCrc, with the checksum of Data.

              The following code:

              X = erlang:crc32(Data1),
              Y = erlang:crc32(X,Data2).

              assigns the same value to Y as this:

              Y = erlang:crc32([Data1,Data2]).

       erlang:crc32_combine(FirstCrc, SecondCrc, SecondSize) ->
                               integer() >= 0

              Types:

                 FirstCrc = SecondCrc = SecondSize = integer() >= 0

              Combines  two previously computed crc32 checksums. This computa-
              tion requires the size of the data object for the second  check-
              sum to be known.

              The following code:

              Y = erlang:crc32(Data1),
              Z = erlang:crc32(Y,Data2).

              assigns the same value to Z as this:

              X = erlang:crc32(Data1),
              Y = erlang:crc32(Data2),
              Z = erlang:crc32_combine(X,Y,iolist_size(Data2)).

       date() -> Date

              Types:

                 Date = calendar:date()

              Returns the current date as {Year, Month, Day}.

              The  time zone and Daylight Saving Time correction depend on the
              underlying OS. Example:

              > date().
              {1995,2,19}

       erlang:decode_packet(Type, Bin, Options) ->
                               {ok, Packet, Rest} |
                               {more, Length} |
                               {error, Reason}

              Types:

                 Type =
                     raw | 0 | 1 | 2 | 4 | asn1 | cdr | sunrm | fcgi | tpkt |
                     line | http | http_bin | httph | httph_bin
                 Bin = binary()
                 Options = [Opt]
                 Opt =
                     {packet_size, integer() >= 0} |
                     {line_length, integer() >= 0}
                 Packet = binary() | HttpPacket
                 Rest = binary()
                 Length = integer() >= 0 | undefined
                 Reason = term()
                 HttpPacket =
                     HttpRequest | HttpResponse  |  HttpHeader  |  http_eoh  |
                 HttpError
                 HttpRequest  =  {http_request,  HttpMethod, HttpUri, HttpVer-
                 sion}
                 HttpResponse =
                     {http_response, HttpVersion, integer(), HttpString}
                 HttpHeader =
                     {http_header,
                      integer(),
                      HttpField,
                      UnmodifiedField :: HttpString,
                      Value :: HttpString}
                 HttpError = {http_error, HttpString}
                 HttpMethod =
                     'OPTIONS' | 'GET' | 'HEAD' | 'POST' | 'PUT' | 'DELETE' |
                     'TRACE' | HttpString
                 HttpUri =
                     '*' |
                     {absoluteURI,
                      http | https,
                      Host :: HttpString,
                      Port :: inet:port_number() | undefined,
                      Path :: HttpString} |
                     {scheme, Scheme :: HttpString, HttpString} |
                     {abs_path, HttpString} |
                     HttpString
                 HttpVersion =
                     {Major :: integer() >= 0, Minor :: integer() >= 0}
                 HttpField =
                     'Cache-Control' | 'Connection' | 'Date' | 'Pragma' |
                     'Transfer-Encoding' | 'Upgrade' | 'Via' | 'Accept' |
                     'Accept-Charset' | 'Accept-Encoding' |  'Accept-Language'
                 |
                     'Authorization' | 'From' | 'Host' | 'If-Modified-Since' |
                     'If-Match' | 'If-None-Match' | 'If-Range' |
                     'If-Unmodified-Since' | 'Max-Forwards' |
                     'Proxy-Authorization'  |  'Range'  |  'Referer'  | 'User-
                 Agent' |
                     'Age' | 'Location' | 'Proxy-Authenticate' | 'Public' |
                     'Retry-After' | 'Server' | 'Vary' | 'Warning' |
                     'Www-Authenticate' | 'Allow' | 'Content-Base' |
                     'Content-Encoding'  |  'Content-Language'   |   'Content-
                 Length' |
                     'Content-Location' | 'Content-Md5' | 'Content-Range' |
                     'Content-Type' | 'Etag' | 'Expires' | 'Last-Modified' |
                     'Accept-Ranges' | 'Set-Cookie' | 'Set-Cookie2' |
                     'X-Forwarded-For' | 'Cookie' | 'Keep-Alive' |
                     'Proxy-Connection' | HttpString
                 HttpString = string() | binary()

              Decodes  the  binary Bin according to the packet protocol speci-
              fied by Type. Similar to the packet  handling  done  by  sockets
              with option {packet,Type}.

              If an entire packet is contained in Bin, it is returned together
              with the remainder of the binary as {ok,Packet,Rest}.

              If Bin does not contain the entire packet, {more,Length} is  re-
              turned.  Length is either the expected total size of the packet,
              or undefined  if  the  expected  packet  size  is  unknown.  de-
              code_packet can then be called again with more data added.

              If  the  packet  does  not  conform to the protocol format, {er-
              ror,Reason} is returned.

              Types:

                raw | 0:
                  No packet handling is done. The entire  binary  is  returned
                  unless it is empty.

                1 | 2 | 4:
                  Packets  consist  of a header specifying the number of bytes
                  in the packet, followed by that number of bytes. The  length
                  of  the  header can be one, two, or four bytes; the order of
                  the bytes is big-endian. The header is stripped off when the
                  packet is returned.

                line:
                  A  packet  is a line-terminated by a delimiter byte, default
                  is the latin-1 newline character. The delimiter byte is  in-
                  cluded  in the returned packet unless the line was truncated
                  according to option line_length.

                asn1 | cdr | sunrm | fcgi | tpkt:
                  The header is not stripped off.

                  The meanings of the packet types are as follows:

                  asn1 - ASN.1 BER:

                  sunrm - Sun's RPC encoding:

                  cdr - CORBA (GIOP 1.1):

                  fcgi - Fast CGI:

                  tpkt - TPKT format [RFC1006]:

                http | httph | http_bin | httph_bin:
                  The Hypertext Transfer Protocol. The  packets  are  returned
                  with the format according to HttpPacket described earlier. A
                  packet is either a request, a response, a header, or an  end
                  of header mark. Invalid lines are returned as HttpError.

                  Recognized request methods and header fields are returned as
                  atoms. Others are returned as strings. Strings  of  unrecog-
                  nized  header fields are formatted with only capital letters
                  first and after hyphen characters,  for  example,  "Sec-Web-
                  socket-Key". Header field names are also returned in Unmodi-
                  fiedField as strings, without any conversion or formatting.

                  The protocol type http is only to be used for the first line
                  when an HttpRequest or an HttpResponse is expected. The fol-
                  lowing calls are to  use  httph  to  get  HttpHeaders  until
                  http_eoh is returned, which marks the end of the headers and
                  the beginning of any following message body.

                  The variants http_bin and httph_bin  return  strings  (Http-
                  String) as binaries instead of lists.

              Options:

                {packet_size, integer() >= 0}:
                  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 con-
                  sidered invalid. Defaults to 0, which means no size limit.

                {line_length, integer() >= 0}:
                  For packet type line, lines longer than the indicated length
                  are truncated.

                  Option  line_length also applies to http* packet types as an
                  alias for option packet_size if packet_size  itself  is  not
                  set. This use is only intended for backward compatibility.

                {line_delimiter, 0 =< byte() =< 255}:
                  For  packet  type line, sets the delimiting byte. Default is
                  the latin-1 character $\n.

              Examples:

              > erlang:decode_packet(1,<<3,"abcd">>,[]).
              {ok,<<"abc">>,<<"d">>}
              > erlang:decode_packet(1,<<5,"abcd">>,[]).
              {more,6}

       erlang:delete_element(Index, Tuple1) -> Tuple2

              Types:

                 Index = integer() >= 1
                   1..tuple_size(Tuple1)
                 Tuple1 = Tuple2 = tuple()

              Returns a new tuple with element at Index removed from tuple Tu-
              ple1, for example:

              > erlang:delete_element(2, {one, two, three}).
              {one,three}

       delete_module(Module) -> true | undefined

              Types:

                 Module = module()

              Makes  the  current  code for Module become old code and deletes
              all references for this module from the  export  table.  Returns
              undefined if the module does not exist, otherwise true.

          Warning:
              This BIF is intended for the code server (see code(3erl)) and is
              not to be used elsewhere.

              Failure: badarg if there already is an old version of Module.

       demonitor(MonitorRef) -> true

              Types:

                 MonitorRef = reference()

              If MonitorRef is a reference that the calling  process  obtained
              by calling monitor/2, this monitoring is turned off. If the mon-
              itoring is already turned off, nothing happens.

              Once demonitor(MonitorRef) has returned, it is  guaranteed  that
              no  {'DOWN',  MonitorRef, _, _, _} message, because of the moni-
              tor, will be placed in the caller message queue in  the  future.
              However,  a  {'DOWN', MonitorRef, _, _, _} message can have been
              placed in the caller message queue before the call. It is there-
              fore  usually advisable to remove such a 'DOWN' message from the
              message queue after monitoring has been stopped. demonitor(Moni-
              torRef, [flush]) can be used instead of demonitor(MonitorRef) if
              this cleanup is wanted.

          Note:
              Before Erlang/OTP R11B (ERTS 5.5) demonitor/1 behaved completely
              asynchronously,  that  is, the monitor was active until the "de-
              monitor signal" reached the monitored entity. This had one unde-
              sirable  effect.  You  could never know when you were guaranteed
              not to receive a DOWN message because of the monitor.

              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.

              Failure: It is an error if MonitorRef  refers  to  a  monitoring
              started  by  another  process.  Not  all such cases are cheap to
              check. If checking is cheap, the call fails with badarg, for ex-
              ample if MonitorRef is a remote reference.

       demonitor(MonitorRef, OptionList) -> boolean()

              Types:

                 MonitorRef = reference()
                 OptionList = [Option]
                 Option = flush | info

              The returned value is true unless info is part of OptionList.

              demonitor(MonitorRef,  [])  is  equivalent to demonitor(Monitor-
              Ref).

              Options:

                flush:
                  Removes (one) {_, MonitorRef, _, _, _} message, if there  is
                  one, from the caller message queue after monitoring has been
                  stopped.

                  Calling demonitor(MonitorRef, [flush]) is equivalent to  the
                  following, but more efficient:

                demonitor(MonitorRef),
                receive
                    {_, MonitorRef, _, _, _} ->
                        true
                after 0 ->
                        true
                end

                info:
                  The returned value is one of the following:

                  true:
                    The monitor was found and removed. In this case, no 'DOWN'
                    message corresponding to this monitor has  been  delivered
                    and will not be delivered.

                  false:
                    The  monitor  was not found and could not be removed. This
                    probably because someone already has placed a 'DOWN'  mes-
                    sage  corresponding  to this monitor in the caller message
                    queue.

                  If option info is combined with option flush, false  is  re-
                  turned if a flush was needed, otherwise true.

          Note:
              More options can be added in a future release.

              Failures:

                badarg:
                  If OptionList is not a list.

                badarg:
                  If Option is an invalid option.

                badarg:
                  The same failure as for demonitor/1.

       disconnect_node(Node) -> boolean() | ignored

              Types:

                 Node = node()

              Forces  the  disconnection  of  a node. This appears to the node
              Node as if the local node has crashed. This BIF is  mainly  used
              in the Erlang network authentication protocols.

              Returns  true if disconnection succeeds, otherwise false. If the
              local node is not alive, ignored is returned.

       erlang:display(Term) -> true

              Types:

                 Term = term()

              Prints a text representation of Term on the standard output.

          Warning:
              This BIF is intended for debugging only.

       erlang:dist_ctrl_get_data(DHandle) -> {Size, Data} | Data | none

              Types:

                 Size = integer() >= 0
                 DHandle = dist_handle()
                 Data = iovec()

              Get distribution channel data from the local node that is to  be
              passed  to  the remote node. The distribution channel is identi-
              fied by DHandle. If no data is available, the atom none  is  re-
              turned.  One  can  request to be informed by a message when more
              data is available by calling erlang:dist_ctrl_get_data_notifica-
              tion(DHandle).

              The  returned value when there are data available depends on the
              value of the get_size  option  configured  on  the  distribution
              channel identified by DHandle. For more information see the doc-
              umentation   of   the    get_size    option    for    the    er-
              lang:dist_ctrl_set_opt/3 function.

          Note:
              Only  the  process registered as distribution controller for the
              distribution channel identified by DHandle is  allowed  to  call
              this function.

              This function is used when implementing an alternative distribu-
              tion carrier using processes as distribution controllers.  DHan-
              dle  is retrived via the callback f_handshake_complete. More in-
              formation can be found in the documentation of ERTS User's Guide
              How to implement an Alternative Carrier for the Erlang Distribu-
              tion  Distribution Module.

       erlang:dist_ctrl_get_opt(DHandle, Opt :: get_size) -> Value

              Types:

                 DHandle = dist_handle()
                 Value = boolean()

              Returns the value of the get_size  option  on  the  distribution
              channel identified by DHandle. For more information see the doc-
              umentation   of   the    get_size    option    for    the    er-
              lang:dist_ctrl_set_opt/3 function.

          Note:
              Only  the  process registered as distribution controller for the
              distribution channel identified by DHandle is  allowed  to  call
              this function.

              This function is used when implementing an alternative distribu-
              tion carrier using processes as distribution controllers.  DHan-
              dle  is retrived via the callback f_handshake_complete. More in-
              formation can be found in the documentation of ERTS User's Guide
              How to implement an Alternative Carrier for the Erlang Distribu-
              tion  Distribution Module.

       erlang:dist_ctrl_get_data_notification(DHandle) -> ok

              Types:

                 DHandle = dist_handle()

              Request notification when more data is available to fetch  using
              erlang:dist_ctrl_get_data(DHandle)  for the distribution channel
              identified by DHandle. When more data  is  present,  the  caller
              will  be  sent  the message dist_data. Once a dist_data messages
              has been sent, no more dist_data messages will be sent until the
              dist_ctrl_get_data_notification/1   function   has  been  called
              again.

          Note:
              Only the process registered as distribution controller  for  the
              distribution  channel  identified  by DHandle is allowed to call
              this function.

              This function is used when implementing an alternative distribu-
              tion  carrier using processes as distribution controllers. DHan-
              dle is retrived via the callback f_handshake_complete. More  in-
              formation can be found in the documentation of ERTS User's Guide
              How to implement an Alternative Carrier for the Erlang Distribu-
              tion  Distribution Module.

       erlang:dist_ctrl_input_handler(DHandle, InputHandler) -> ok

              Types:

                 DHandle = dist_handle()
                 InputHandler = pid()

              Register an alternate input handler process for the distribution
              channel identified by  DHandle.  Once  this  function  has  been
              called,  InputHandler  is  the  only process allowed to call er-
              lang:dist_ctrl_put_data(DHandle, Data) with the DHandle  identi-
              fing this distribution channel.

          Note:
              Only  the  process registered as distribution controller for the
              distribution channel identified by DHandle is  allowed  to  call
              this function.

              This function is used when implementing an alternative distribu-
              tion carrier using processes as distribution controllers.  DHan-
              dle  is retrived via the callback f_handshake_complete. More in-
              formation can be found in the documentation of ERTS User's Guide
              How to implement an Alternative Carrier for the Erlang Distribu-
              tion  Distribution Module.

       erlang:dist_ctrl_put_data(DHandle, Data) -> ok

              Types:

                 DHandle = dist_handle()
                 Data = iodata()

              Deliver distribution channel data from a remote node to the  lo-
              cal node.

          Note:
              Only  the  process registered as distribution controller for the
              distribution channel identified by DHandle is  allowed  to  call
              this function unless an alternate input handler process has been
              registered  using  erlang:dist_ctrl_input_handler(DHandle,   In-
              putHandler).  If an alternate input handler has been registered,
              only the registered input handler process  is  allowed  to  call
              this function.

              This function is used when implementing an alternative distribu-
              tion carrier using processes as distribution controllers.  DHan-
              dle  is retrived via the callback f_handshake_complete. More in-
              formation can be found in the documentation of ERTS User's Guide
              How to implement an Alternative Carrier for the Erlang Distribu-
              tion  Distribution Module.

       erlang:dist_ctrl_set_opt(DHandle, Opt :: get_size, Value) ->
                                   OldValue

              Types:

                 DHandle = dist_handle()
                 Value = OldValue = boolean()

              Sets the value of the get_size option on the distribution  chan-
              nel identified by DHandle. This option controls the return value
              of calls  to  erlang:dist_ctrl_get_data(DHandle)  where  DHandle
              equals  DHandle used when setting this option. When the get_size
              option is:

                false:
                   and there are distribution data available, a  call  to  er-
                  lang:dist_ctrl_get_data(DHandle)  will  just  return Data to
                  pass over the channel. This is  the  default  value  of  the
                  get_size option.

                true:
                   and  there  are  distribution data available, a call to er-
                  lang:dist_ctrl_get_data(DHandle) will return  Data  to  pass
                  over  the channel as well as the Size of Data in bytes. This
                  is returned as a tuple on the form {Size, Data}.

              All options are set to default when a channel is closed.

          Note:
              Only the process registered as distribution controller  for  the
              distribution  channel  identified  by DHandle is allowed to call
              this function.

              This function is used when implementing an alternative distribu-
              tion  carrier using processes as distribution controllers. DHan-
              dle is retrived via the callback f_handshake_complete. More  in-
              formation can be found in the documentation of ERTS User's Guide
              How to implement an Alternative Carrier for the Erlang Distribu-
              tion  Distribution Module.

       element(N, Tuple) -> term()

              Types:

                 N = integer() >= 1
                   1..tuple_size(Tuple)
                 Tuple = tuple()

              Returns  the  Nth element (numbering from 1) of Tuple, for exam-
              ple:

              > element(2, {a, b, c}).
              b

              Allowed in guard tests.

       erase() -> [{Key, Val}]

              Types:

                 Key = Val = term()

              Returns the process dictionary and deletes it, for example:

              > put(key1, {1, 2, 3}),
              put(key2, [a, b, c]),
              erase().
              [{key1,{1,2,3}},{key2,[a,b,c]}]

       erase(Key) -> Val | undefined

              Types:

                 Key = Val = term()

              Returns the value Val associated with Key and  deletes  it  from
              the process dictionary. Returns undefined if no value is associ-
              ated with Key. Example:

              > put(key1, {merry, lambs, are, playing}),
              X = erase(key1),
              {X, erase(key1)}.
              {{merry,lambs,are,playing},undefined}

       error(Reason) -> no_return()

              Types:

                 Reason = term()

              Stops the execution of the calling process with the reason  Rea-
              son,  where  Reason  is  any  term.  The exit reason is {Reason,
              Where}, where Where is a list of  the  functions  most  recently
              called (the current function first). As evaluating this function
              causes the process to terminate, it has no return  value.  Exam-
              ple:

              > catch error(foobar).
              {'EXIT',{foobar,[{shell,apply_fun,3,
                                      [{file,"shell.erl"},{line,906}]},
                               {erl_eval,do_apply,6,[{file,"erl_eval.erl"},{line,677}]},
                               {erl_eval,expr,5,[{file,"erl_eval.erl"},{line,430}]},
                               {shell,exprs,7,[{file,"shell.erl"},{line,687}]},
                               {shell,eval_exprs,7,[{file,"shell.erl"},{line,642}]},
                               {shell,eval_loop,3,[{file,"shell.erl"},{line,627}]}]}}

       error(Reason, Args) -> no_return()

              Types:

                 Reason = term()
                 Args = [term()]

              Stops  the execution of the calling process with the reason Rea-
              son, where Reason is any  term.  The  exit  reason  is  {Reason,
              Where},  where  Where  is  a list of the functions most recently
              called (the current function first). Args 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
              Where.  As evaluating this function causes the process to termi-
              nate, it has no return value.

       exit(Reason) -> no_return()

              Types:

                 Reason = term()

              Stops the execution of the calling process with exit reason Rea-
              son,  where  Reason  is  any  term.  As evaluating this function
              causes the process to terminate, it has no return  value.  Exam-
              ple:

              > exit(foobar).
              ** exception exit: foobar
              > catch exit(foobar).
              {'EXIT',foobar}

       exit(Pid, Reason) -> true

              Types:

                 Pid = pid() | port()
                 Reason = term()

              Sends  an  exit signal with exit reason Reason to the process or
              port identified by Pid.

              The following behavior applies if Reason  is  any  term,  except
              normal or kill:

                * If  Pid  is  not  trapping exits, Pid itself exits with exit
                  reason Reason.

                * If Pid is trapping exits, the  exit  signal  is  transformed
                  into  a  message {'EXIT', From, Reason} and delivered to the
                  message queue of Pid.

                * From is the process identifier of the process that sent  the
                  exit signal. See also process_flag/2.

              If  Reason is the atom normal, Pid does not exit. If it is trap-
              ping exits, the  exit  signal  is  transformed  into  a  message
              {'EXIT', From, normal} and delivered to its message queue.

              If  Reason  is  the  atom  kill,  that is, if exit(Pid, kill) is
              called, an untrappable exit signal is sent to Pid, which  uncon-
              ditionally exits with exit reason killed.

       erlang:external_size(Term) -> integer() >= 0

              Types:

                 Term = term()

              Calculates,  without  doing  the encoding, the maximum byte size
              for a term encoded in the Erlang external term format. The  fol-
              lowing condition applies always:

              > Size1 = byte_size(term_to_binary(Term)),
              > Size2 = erlang:external_size(Term),
              > true = Size1 =< Size2.
              true

              This is equivalent to a call to:

              erlang:external_size(Term, [])

       erlang:external_size(Term, Options) -> integer() >= 0

              Types:

                 Term = term()
                 Options = [{minor_version, Version :: integer() >= 0}]

              Calculates,  without  doing  the encoding, the maximum byte size
              for a term encoded in the Erlang external term format. The  fol-
              lowing condition applies always:

              > Size1 = byte_size(term_to_binary(Term, Options)),
              > Size2 = erlang:external_size(Term, Options),
              > true = Size1 =< Size2.
              true

              Option  {minor_version,  Version}  specifies  how floats are en-
              coded. For a detailed description, see term_to_binary/2.

       float(Number) -> float()

              Types:

                 Number = number()

              Returns a float by converting Number to a float, for example:

              > float(55).
              55.0

              Allowed in guard tests.

          Note:
              If used on the top level in a guard, it tests whether the  argu-
              ment is a floating point number; for clarity, use is_float/1 in-
              stead.

              When float/1 is used in  an  expression  in  a  guard,  such  as
              'float(A) == 4.0', it converts a number as described earlier.

       float_to_binary(Float) -> binary()

              Types:

                 Float = float()

              The same as float_to_binary(Float,[{scientific,20}]).

       float_to_binary(Float, Options) -> binary()

              Types:

                 Float = float()
                 Options = [Option]
                 Option =
                     {decimals, Decimals :: 0..253} |
                     {scientific, Decimals :: 0..249} |
                     compact

              Returns  a  binary  corresponding  to the text representation of
              Float using fixed decimal point formatting. Options  behaves  in
              the same way as float_to_list/2. Examples:

              > float_to_binary(7.12, [{decimals, 4}]).
              <<"7.1200">>
              > float_to_binary(7.12, [{decimals, 4}, compact]).
              <<"7.12">>

       float_to_list(Float) -> string()

              Types:

                 Float = float()

              The same as float_to_list(Float,[{scientific,20}]).

       float_to_list(Float, Options) -> string()

              Types:

                 Float = float()
                 Options = [Option]
                 Option =
                     {decimals, Decimals :: 0..253} |
                     {scientific, Decimals :: 0..249} |
                     compact

              Returns  a  string  corresponding  to the text representation of
              Float using fixed decimal point formatting.

              Available options:

                * If option decimals is specified, the returned value contains
                  at most Decimals number of digits past the decimal point. If
                  the number does not fit in the internal static buffer of 256
                  bytes, the function throws badarg.

                * If  option  compact  is specified, the trailing zeros at the
                  end of the list are truncated. This option is only  meaning-
                  ful together with option decimals.

                * If  option  scientific  is specified, the float is formatted
                  using scientific notation with Decimals digits of precision.

                * If Options is [], the function behaves as float_to_list/1.

              Examples:

              > float_to_list(7.12, [{decimals, 4}]).
              "7.1200"
              > float_to_list(7.12, [{decimals, 4}, compact]).
              "7.12"

       floor(Number) -> integer()

              Types:

                 Number = number()

              Returns the largest integer not greater than Number.  For  exam-
              ple:

              > floor(-10.5).
              -11

              Allowed in guard tests.

       erlang:fun_info(Fun) -> [{Item, Info}]

              Types:

                 Fun = function()
                 Item =
                     arity  |  env  |  index  |  name  |  module | new_index |
                 new_uniq |
                     pid | type | uniq
                 Info = term()

              Returns a list with information about the fun Fun. Each list el-
              ement is a tuple. The order of the tuples is undefined, and more
              tuples can be added in a future release.

          Warning:
              This BIF is mainly intended for debugging, but it can  sometimes
              be useful in library functions that need to verify, for example,
              the arity of a fun.

              Two types of funs have slightly different semantics:

                * A fun created by fun M:F/A is called an external fun.  Call-
                  ing  it  will always call the function F with arity A in the
                  latest code for module M. Notice that module M does not even
                  need to be loaded when the fun fun M:F/A is created.

                * All other funs are called local. 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).

              The  following  elements are always present in the list for both
              local and external funs:

                {type, Type}:
                  Type is local or external.

                {module, Module}:
                  Module (an atom) is the module name.

                  If Fun is a local fun, Module is the module in which the fun
                  is defined.

                  If Fun is an external fun, Module is the module that the fun
                  refers to.

                {name, Name}:
                  Name (an atom) is a function name.

                  If Fun is a local fun, Name is the name of the  local  func-
                  tion  that  implements  the fun. (This name was generated by
                  the compiler, and is only of informational use. As it  is  a
                  local function, it cannot be called directly.) If no code is
                  currently loaded for the fun, [] is returned instead  of  an
                  atom.

                  If  Fun is an external fun, Name is the name of the exported
                  function that the fun refers to.

                {arity, Arity}:
                  Arity is the number of arguments  that  the  fun  is  to  be
                  called with.

                {env, Env}:
                  Env  (a  list)  is the environment or free variables for the
                  fun. For external funs, the returned list is always empty.

              The following elements are only present in the list  if  Fun  is
              local:

                {pid, Pid}:
                  Pid is the process identifier of the process that originally
                  created the fun.

                  It might point to the init process if the Fun was statically
                  allocated  when module was loaded (this optimisation is per-
                  formed for local functions that do not capture the  environ-
                  ment).

                {index, Index}:
                  Index (an integer) is an index into the module fun table.

                {new_index, Index}:
                  Index (an integer) is an index into the module fun table.

                {new_uniq, Uniq}:
                  Uniq (a binary) is a unique value for this fun. It is calcu-
                  lated from the compiled code for the entire module.

                {uniq, Uniq}:
                  Uniq (an integer) is a unique value for this  fun.  As  from
                  Erlang/OTP R15, this integer is calculated from the compiled
                  code for the entire module. Before Erlang/OTP R15, this  in-
                  teger was based on only the body of the fun.

       erlang:fun_info(Fun, Item) -> {Item, Info}

              Types:

                 Fun = function()
                 Item = fun_info_item()
                 Info = term()
                 fun_info_item() =
                     arity | env | index | name | module | new_index | new_uniq |
                     pid | type | uniq

              Returns  information about Fun as specified by Item, in the form
              {Item,Info}.

              For any fun, Item can be any of the atoms module,  name,  arity,
              env, or type.

              For  a  local  fun,  Item  can  also  be any of the atoms index,
              new_index, new_uniq, uniq, and pid. For  an  external  fun,  the
              value of any of these items is always the atom undefined.

              See erlang:fun_info/1.

       erlang:fun_to_list(Fun) -> string()

              Types:

                 Fun = function()

              Returns  a  string  corresponding  to the text representation of
              Fun.

       erlang:function_exported(Module, Function, Arity) -> boolean()

              Types:

                 Module = module()
                 Function = atom()
                 Arity = arity()

              Returns true if the module Module is loaded and contains an  ex-
              ported function Function/Arity, or if there is a BIF (a built-in
              function implemented in C) with the  specified  name,  otherwise
              returns false.

          Note:
              This  function  used  to return false for BIFs before Erlang/OTP
              18.0.

       garbage_collect() -> true

              Forces an immediate garbage collection of the executing process.
              The  function  is  not to be used unless it has been noticed (or
              there are good reasons to suspect) that the spontaneous  garbage
              collection will occur too late or not at all.

          Warning:
              Improper use can seriously degrade system performance.

       garbage_collect(Pid) -> GCResult

              Types:

                 Pid = pid()
                 GCResult = boolean()

              The same as garbage_collect(Pid, []).

       garbage_collect(Pid, OptionList) -> GCResult | async

              Types:

                 Pid = pid()
                 RequestId = term()
                 Option = {async, RequestId} | {type, major | minor}
                 OptionList = [Option]
                 GCResult = boolean()

              Garbage collects the node local process identified by Pid.

              Option:

                {async, RequestId}:
                  The function garbage_collect/2 returns the value async imme-
                  diately 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  {garbage_collect,  RequestId,
                  GCResult}.

                {type, 'major' | 'minor'}:
                  Triggers garbage collection of requested type. Default value
                  is 'major', which would trigger a fullsweep GC.  The  option
                  'minor' is considered a hint and may lead to either minor or
                  major GC run.

              If Pid equals self(), and no async option has been  passed,  the
              garbage  collection  is  performed at once, that is, the same as
              calling garbage_collect/0. Otherwise a request for garbage  col-
              lection  is  sent  to the process identified by Pid, and will be
              handled when appropriate. If no async option  has  been  passed,
              the  caller  blocks  until  GCResult is available and can be re-
              turned.

              GCResult informs about the result of the garbage collection  re-
              quest as follows:

                true:
                   The process identified by Pid has been garbage collected.

                false:
                   No garbage collection was performed, as the process identi-
                  fied by Pid terminated before the request  could  be  satis-
                  fied.

              Notice that the same caveats apply as for garbage_collect/0.

              Failures:

                badarg:
                   If Pid is not a node local process identifier.

                badarg:
                   If OptionList is an invalid list of options.

       get() -> [{Key, Val}]

              Types:

                 Key = Val = term()

              Returns  the  process dictionary as a list of {Key, Val} tuples,
              for example:

              > put(key1, merry),
              put(key2, lambs),
              put(key3, {are, playing}),
              get().
              [{key1,merry},{key2,lambs},{key3,{are,playing}}]

       get(Key) -> Val | undefined

              Types:

                 Key = Val = term()

              Returns the value Val associated with Key in the process dictio-
              nary, or undefined if Key does not exist. Example:

              > put(key1, merry),
              put(key2, lambs),
              put({any, [valid, term]}, {are, playing}),
              get({any, [valid, term]}).
              {are,playing}

       erlang:get_cookie() -> Cookie | nocookie

              Types:

                 Cookie = atom()

              Returns the magic cookie of the local node if the node is alive,
              otherwise the atom nocookie.

       get_keys() -> [Key]

              Types:

                 Key = term()

              Returns a list of all keys present in  the  process  dictionary,
              for example:

              > put(dog, {animal,1}),
              put(cow, {animal,2}),
              put(lamb, {animal,3}),
              get_keys().
              [dog,cow,lamb]

       get_keys(Val) -> [Key]

              Types:

                 Val = Key = term()

              Returns a list of keys that are associated with the value Val in
              the process dictionary, for example:

              > put(mary, {1, 2}),
              put(had, {1, 2}),
              put(a, {1, 2}),
              put(little, {1, 2}),
              put(dog, {1, 3}),
              put(lamb, {1, 2}),
              get_keys({1, 2}).
              [mary,had,a,little,lamb]

       erlang:get_stacktrace() -> [stack_item()]

              Types:

                 stack_item() =
                     {Module :: module(),
                      Function :: atom(),
                      Arity :: arity() | (Args :: [term()]),
                      Location ::
                          [{file, Filename :: string()} |
                           {line, Line :: integer() >= 1}]}

          Warning:
              erlang:get_stacktrace/0 is deprecated and will be removed in OTP
              24. Starting from OTP 23, erlang:get_stacktrace/0 returns [].

              Instead  of  using  erlang:get_stacktrace/0 to retrieve the call
              stack back-trace, use the following syntax:

              try Expr
              catch
                Class:Reason:Stacktrace ->
                 {Class,Reason,Stacktrace}
              end

       group_leader() -> pid()

              Returns the process identifier  of  the  group  leader  for  the
              process evaluating the function.

              Every  process  is a member of some process group and all groups
              have a group leader. 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
              startup,  init is both its own group leader and the group leader
              of all processes.

       group_leader(GroupLeader, Pid) -> true

              Types:

                 GroupLeader = Pid = pid()

              Sets the group leader of Pid to GroupLeader. Typically, this  is
              used  when a process started from a certain shell is to have an-
              other group leader than init.

              The group leader should be rarely changed in applications with a
              supervision  tree, because OTP assumes the group leader of their
              processes is their application master.

              See also group_leader/0 and OTP  design  principles  related  to
              starting and stopping applications.

       halt() -> no_return()

              The same as halt(0, []). Example:

              > halt().
              os_prompt%

       halt(Status) -> no_return()

              Types:

                 Status = integer() >= 0 | abort | string()

              The same as halt(Status, []). Example:

              > halt(17).
              os_prompt% echo $?
              17
              os_prompt%

       halt(Status, Options) -> no_return()

              Types:

                 Status = integer() >= 0 | abort | string()
                 Options = [Option]
                 Option = {flush, boolean()}

              Status  must  be  a  non-negative integer, a string, or the atom
              abort. Halts the Erlang runtime system. Has no return value. De-
              pending on Status, the following occurs:

                integer():
                  The runtime system exits with integer value Status as status
                  code to the calling environment (OS).

            Note:
                On many platforms, the OS supports only status codes 0-255.  A
                too large status code is truncated by clearing the high bits.

                string():
                  An Erlang crash dump is produced with Status as slogan. Then
                  the runtime system exits with status code 1. The string will
                  be truncated if longer than 200 characters.

            Note:
                Before ERTS 9.1 (OTP-20.1) only code points in the range 0-255
                was accepted in the string. Now any unicode string is valid.

                abort:
                  The runtime system aborts producing a core dump, if that  is
                  enabled in the OS.

              For  integer  Status, the Erlang runtime system closes all ports
              and allows async threads to finish their operations before exit-
              ing. To exit without such flushing, use Option as {flush,false}.

              For  statuses  string()  and  abort, option flush is ignored and
              flushing is not done.

       hd(List) -> term()

              Types:

                 List = [term(), ...]

              Returns the head of List, that is, the first element, for  exam-
              ple:

              > hd([1,2,3,4,5]).
              1

              Allowed in guard tests.

              Failure: badarg if List is the empty list [].

       erlang:hibernate(Module, Function, Args) -> no_return()

              Types:

                 Module = module()
                 Function = atom()
                 Args = [term()]

              Puts  the calling process into a wait state where its memory al-
              location has been reduced as much as possible. This is useful if
              the process does not expect to receive any messages soon.

              The  process is awaken when a message is sent to it, and control
              resumes in Module:Function with the arguments specified by  Args
              with the call stack emptied, meaning that the process terminates
              when that function returns. Thus  erlang:hibernate/3  never  re-
              turns to its caller.

              If the process has any message in its message queue, the process
              is awakened immediately in the same way as described earlier.

              In more technical terms, erlang:hibernate/3  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 that it
              holds (even if that size is less than the minimum heap size  for
              the process).

              If  the  size  of  the live data in the process is less than the
              minimum heap size, the first garbage collection occurring  after
              the process is awakened ensures that the heap size is changed to
              a size not smaller than the minimum heap size.

              Notice that emptying the call stack means that  any  surrounding
              catch  is removed and must be re-inserted after hibernation. One
              effect of this is that processes started  using  proc_lib  (also
              indirectly,   such   as   gen_server   processes),  are  to  use
              proc_lib:hibernate/3 instead, to ensure that the exception  han-
              dler continues to work when the process wakes up.

       erlang:insert_element(Index, Tuple1, Term) -> Tuple2

              Types:

                 Index = integer() >= 1
                   1..tuple_size(Tuple1) + 1
                 Tuple1 = Tuple2 = tuple()
                 Term = term()

              Returns a new tuple with element Term inserted at position Index
              in tuple Tuple1. All elements from position  Index  and  upwards
              are pushed one step higher in the new tuple Tuple2. Example:

              > erlang:insert_element(2, {one, two, three}, new).
              {one,new,two,three}

       integer_to_binary(Integer) -> binary()

              Types:

                 Integer = integer()

              Returns a binary corresponding to the text representation of In-
              teger, for example:

              > integer_to_binary(77).
              <<"77">>

       integer_to_binary(Integer, Base) -> binary()

              Types:

                 Integer = integer()
                 Base = 2..36

              Returns a binary corresponding to the text representation of In-
              teger in base Base, for example:

              > integer_to_binary(1023, 16).
              <<"3FF">>

       integer_to_list(Integer) -> string()

              Types:

                 Integer = integer()

              Returns a string corresponding to the text representation of In-
              teger, for example:

              > integer_to_list(77).
              "77"

       integer_to_list(Integer, Base) -> string()

              Types:

                 Integer = integer()
                 Base = 2..36

              Returns a string corresponding to the text representation of In-
              teger in base Base, for example:

              > integer_to_list(1023, 16).
              "3FF"

       iolist_size(Item) -> integer() >= 0

              Types:

                 Item = iolist() | binary()

              Returns  an  integer,  that  is the size in bytes, of the binary
              that would be the result of iolist_to_binary(Item), for example:

              > iolist_size([1,2|<<3,4>>]).
              4

       iolist_to_binary(IoListOrBinary) -> binary()

              Types:

                 IoListOrBinary = iolist() | binary()

              Returns a binary that is made from the integers and binaries  in
              IoListOrBinary, for example:

              > Bin1 = <<1,2,3>>.
              <<1,2,3>>
              > Bin2 = <<4,5>>.
              <<4,5>>
              > Bin3 = <<6>>.
              <<6>>
              > iolist_to_binary([Bin1,1,[2,3,Bin2],4|Bin3]).
              <<1,2,3,1,2,3,4,5,4,6>>

       erlang:iolist_to_iovec(IoListOrBinary) -> iovec()

              Types:

                 IoListOrBinary = iolist() | binary()

              Returns  an iovec that is made from the integers and binaries in
              IoListOrBinary.

       is_alive() -> boolean()

              Returns true if the local node is alive (that is,  if  the  node
              can be part of a distributed system), otherwise false.

       is_atom(Term) -> boolean()

              Types:

                 Term = term()

              Returns true if Term is an atom, otherwise false.

              Allowed in guard tests.

       is_binary(Term) -> boolean()

              Types:

                 Term = term()

              Returns true if Term is a binary, otherwise false.

              A binary always contains a complete number of bytes.

              Allowed in guard tests.

       is_bitstring(Term) -> boolean()

              Types:

                 Term = term()

              Returns true if Term is a bitstring (including a binary), other-
              wise false.

              Allowed in guard tests.

       is_boolean(Term) -> boolean()

              Types:

                 Term = term()

              Returns true if Term is the atom true or the  atom  false  (that
              is, a boolean). Otherwise returns false.

              Allowed in guard tests.

       erlang:is_builtin(Module, Function, Arity) -> boolean()

              Types:

                 Module = module()
                 Function = atom()
                 Arity = arity()

              This BIF is useful for builders of cross-reference tools.

              Returns true if Module:Function/Arity is a BIF implemented in C,
              otherwise false.

       is_float(Term) -> boolean()

              Types:

                 Term = term()

              Returns true if Term  is  a  floating  point  number,  otherwise
              false.

              Allowed in guard tests.

       is_function(Term) -> boolean()

              Types:

                 Term = term()

              Returns true if Term is a fun, otherwise false.

              Allowed in guard tests.

       is_function(Term, Arity) -> boolean()

              Types:

                 Term = term()
                 Arity = arity()

              Returns  true  if  Term  is a fun that can be applied with Arity
              number of arguments, otherwise false.

              Allowed in guard tests.

       is_integer(Term) -> boolean()

              Types:

                 Term = term()

              Returns true if Term is an integer, otherwise false.

              Allowed in guard tests.

       is_list(Term) -> boolean()

              Types:

                 Term = term()

              Returns true if Term is a list with zero or more elements,  oth-
              erwise false.

              Allowed in guard tests.

       is_map(Term) -> boolean()

              Types:

                 Term = term()

              Returns true if Term is a map, otherwise false.

              Allowed in guard tests.

       is_map_key(Key, Map) -> boolean()

              Types:

                 Key = term()
                 Map = map()

              Returns  true  if  map  Map contains Key and returns false if it
              does not contain the Key.

              The call fails with a {badmap,Map} exception if  Map  is  not  a
              map.

              Example:

              > Map = #{"42" => value}.
              #{"42" => value}
              > is_map_key("42",Map).
              true
              > is_map_key(value,Map).
              false

              Allowed in guard tests.

       is_number(Term) -> boolean()

              Types:

                 Term = term()

              Returns  true  if Term is an integer or a floating point number.
              Otherwise returns false.

              Allowed in guard tests.

       is_pid(Term) -> boolean()

              Types:

                 Term = term()

              Returns true if Term is a process identifier, otherwise false.

              Allowed in guard tests.

       is_port(Term) -> boolean()

              Types:

                 Term = term()

              Returns true if Term is a port identifier, otherwise false.

              Allowed in guard tests.

       is_process_alive(Pid) -> boolean()

              Types:

                 Pid = pid()

              Pid must refer to a process at the local node.

              Returns true if the process exists and is alive, that is, is not
              exiting and has not exited. Otherwise returns false.

       is_record(Term, RecordTag) -> boolean()

              Types:

                 Term = term()
                 RecordTag = atom()

              Returns true if Term is a tuple and its first element is Record-
              Tag. Otherwise returns false.

          Note:
              Normally the compiler treats calls to is_record/2 especially. It
              emits  code  to verify that Term is a tuple, that its first ele-
              ment is RecordTag, and that the size  is  correct.  However,  if
              RecordTag  is  not a literal atom, the BIF is_record/2 is called
              instead and the size of the tuple is not verified.

              Allowed in guard tests, if RecordTag is a literal atom.

       is_record(Term, RecordTag, Size) -> boolean()

              Types:

                 Term = term()
                 RecordTag = atom()
                 Size = integer() >= 0

              RecordTag must be an atom.

              Returns true if Term is a tuple, its first element is RecordTag,
              and its size is Size. Otherwise returns false.

              Allowed  in  guard tests if RecordTag is a literal atom and Size
              is a literal integer.

          Note:
              This BIF is documented for completeness. Usually is_record/2  is
              to be used.

       is_reference(Term) -> boolean()

              Types:

                 Term = term()

              Returns true if Term is a reference, otherwise false.

              Allowed in guard tests.

       is_tuple(Term) -> boolean()

              Types:

                 Term = term()

              Returns true if Term is a tuple, otherwise false.

              Allowed in guard tests.

       length(List) -> integer() >= 0

              Types:

                 List = [term()]

              Returns the length of List, for example:

              > length([1,2,3,4,5,6,7,8,9]).
              9

              Allowed in guard tests.

       link(PidOrPort) -> true

              Types:

                 PidOrPort = pid() | port()

              Creates  a  link between the calling process and another process
              (or port) PidOrPort. If the link already exists or a process at-
              tempts to create a link to itself, nothing is done. Returns true
              if the link is set up.

              If PidOrPort does not exist and checking it is cheap,  a  noproc
              error  is  raised. Currently, checking is cheap if the PidOrPort
              is local and the caller does not trap exits (see  process_flag/2
              ).

              Apart  from any exit signals from the linked process itself, two
              special exit signals may be sent to the calling process:

                * noproc is sent immediately if PidOrPort does  not  exist  at
                  the  time of linking (if the caller is trapping exits or Pi-
                  dOrPort is remote).

                * noconnection if PidOrPort is remote and a connection between
                  the nodes could not be established or was severed.

              See Processes  Links in the Erlang Reference Manual for more de-
              tails.

       list_to_atom(String) -> atom()

              Types:

                 String = string()

              Returns the atom whose text representation is String.

              As from Erlang/OTP 20, String may contain any Unicode character.
              Earlier  versions allowed only ISO-latin-1 characters as the im-
              plementation did not allow Unicode  characters  above  255.  For
              more  information on Unicode support in atoms, see note on UTF-8
              encoded atoms in section "External Term Format"  in  the  User's
              Guide.

              Example:

              > list_to_atom("Erlang").
              'Erlang'

       list_to_binary(IoList) -> binary()

              Types:

                 IoList = iolist()

              Returns  a binary that is made from the integers and binaries in
              IoList, for example:

              > Bin1 = <<1,2,3>>.
              <<1,2,3>>
              > Bin2 = <<4,5>>.
              <<4,5>>
              > Bin3 = <<6>>.
              <<6>>
              > list_to_binary([Bin1,1,[2,3,Bin2],4|Bin3]).
              <<1,2,3,1,2,3,4,5,4,6>>

       list_to_bitstring(BitstringList) -> bitstring()

              Types:

                 BitstringList = bitstring_list()
                 bitstring_list() =
                     maybe_improper_list(byte() | bitstring() | bitstring_list(),
                                         bitstring() | [])

              Returns a bitstring that is made  from  the  integers  and  bit-
              strings in BitstringList. (The last tail in BitstringList is al-
              lowed to be a bitstring.) Example:

              > Bin1 = <<1,2,3>>.
              <<1,2,3>>
              > Bin2 = <<4,5>>.
              <<4,5>>
              > Bin3 = <<6,7:4>>.
              <<6,7:4>>
              > list_to_bitstring([Bin1,1,[2,3,Bin2],4|Bin3]).
              <<1,2,3,1,2,3,4,5,4,6,7:4>>

       list_to_existing_atom(String) -> atom()

              Types:

                 String = string()

              Returns the atom whose text representation is String,  but  only
              if there already exists such atom.

              Failure:  badarg  if  there does not already exist an atom whose
              text representation is String.

          Note:
              Note that the compiler may optimize away atoms. For example, the
              compiler will rewrite atom_to_list(some_atom) to "some_atom". If
              that expression is the only mention of the atom some_atom in the
              containing  module, the atom will not be created when the module
              is   loaded,   and   a   subsequent   call   to   list_to_exist-
              ing_atom("some_atom") will fail.

       list_to_float(String) -> float()

              Types:

                 String = string()

              Returns the float whose text representation is String, for exam-
              ple:

              > list_to_float("2.2017764e+0").
              2.2017764

              Failure: badarg if String contains a  bad  representation  of  a
              float.

       list_to_integer(String) -> integer()

              Types:

                 String = string()

              Returns  an integer whose text representation is String, for ex-
              ample:

              > list_to_integer("123").
              123

              Failure: badarg if String contains a bad  representation  of  an
              integer.

       list_to_integer(String, Base) -> integer()

              Types:

                 String = string()
                 Base = 2..36

              Returns  an  integer  whose  text representation in base Base is
              String, for example:

              > list_to_integer("3FF", 16).
              1023

              Failure: badarg if String contains a bad  representation  of  an
              integer.

       list_to_pid(String) -> pid()

              Types:

                 String = string()

              Returns  a  process  identifier  whose  text representation is a
              String, for example:

              > list_to_pid("<0.4.1>").
              <0.4.1>

              Failure: badarg if String contains a  bad  representation  of  a
              process identifier.

          Warning:
              This  BIF is intended for debugging and is not to be used in ap-
              plication programs.

       list_to_port(String) -> port()

              Types:

                 String = string()

              Returns a port identifier whose text representation is a String,
              for example:

              > list_to_port("#Port<0.4>").
              #Port<0.4>

              Failure:  badarg  if  String  contains a bad representation of a
              port identifier.

          Warning:
              This BIF is intended for debugging and is not to be used in  ap-
              plication programs.

       list_to_ref(String) -> reference()

              Types:

                 String = string()

              Returns  a  reference whose text representation is a String, for
              example:

              > list_to_ref("#Ref<0.4192537678.4073193475.71181>").
              #Ref<0.4192537678.4073193475.71181>

              Failure: badarg if String contains a  bad  representation  of  a
              reference.

          Warning:
              This  BIF is intended for debugging and is not to be used in ap-
              plication programs.

       list_to_tuple(List) -> tuple()

              Types:

                 List = [term()]

              Returns a tuple corresponding to List, for example

              > list_to_tuple([share, ['Ericsson_B', 163]]).
              {share, ['Ericsson_B', 163]}

              List can contain any Erlang terms.

       load_module(Module, Binary) -> {module, Module} | {error, Reason}

              Types:

                 Module = module()
                 Binary = binary()
                 Reason = badfile | not_purged | on_load

              If Binary contains the object code for module Module,  this  BIF
              loads  that  object  code. If the code for module Module already
              exists, all export references are replaced so they point to  the
              newly  loaded  code.  The  previously loaded code is kept in the
              system as old code, as there can still  be  processes  executing
              that code.

              Returns  either  {module, Module}, or {error, Reason} if loading
              fails. Reason is one of the following:

                badfile:
                  The object code in Binary has an incorrect format or the ob-
                  ject code contains code for another module than Module.

                not_purged:
                  Binary  contains  a module that cannot be loaded because old
                  code for this module already exists.

          Warning:
              This BIF is intended for the code server (see code(3erl)) and is
              not to be used elsewhere.

       erlang:load_nif(Path, LoadInfo) -> ok | Error

              Types:

                 Path = string()
                 LoadInfo = term()
                 Error = {error, {Reason, Text :: string()}}
                 Reason =
                     load_failed  |  bad_lib  |  load  |  reload  |  upgrade |
                 old_code

              Loads and links a dynamic library containing native  implemented
              functions (NIFs) for a module. Path is a file path to the share-
              able object/dynamic library file minus the OS-dependent file ex-
              tension (.so for Unix and .dll for Windows). Notice that on most
              OSs the library has to have a different name on disc when an up-
              grade  of the nif is done. If the name is the same, but the con-
              tents differ, the old library may be loaded instead. For  infor-
              mation on how to implement a NIF library, see erl_nif(3erl).

              LoadInfo 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.

              The  call  to  load_nif/2  must be made directly from the Erlang
              code of the module that the NIF library belongs to.  It  returns
              either  ok, or {error,{Reason,Text}} if loading fails. Reason is
              one of the following atoms while Text is a human readable string
              that can give more information about the failure:

                load_failed:
                  The OS failed to load the NIF library.

                bad_lib:
                  The  library  did  not fulfill the requirements as a NIF li-
                  brary of the calling module.

                load | upgrade:
                  The corresponding library callback was unsuccessful.

                reload:
                  A NIF library is already loaded for  this  module  instance.
                  The  previously deprecated reload feature was removed in OTP
                  20.

                old_code:
                  The call to load_nif/2 was made from the old code of a  mod-
                  ule that has been upgraded; this is not allowed.

                notsup:
                  Lack of support. Such as loading NIF library for a HiPE com-
                  piled module.

       erlang:loaded() -> [Module]

              Types:

                 Module = module()

              Returns a list of all loaded Erlang  modules  (current  and  old
              code), including preloaded modules.

              See also code(3erl).

       erlang:localtime() -> DateTime

              Types:

                 DateTime = calendar:datetime()

              Returns  the  current  local date and time, {{Year, Month, Day},
              {Hour, Minute, Second}}, for example:

              > erlang:localtime().
              {{1996,11,6},{14,45,17}}

              The time zone and Daylight Saving Time correction depend on  the
              underlying OS.

       erlang:localtime_to_universaltime(Localtime) -> Universaltime

              Types:

                 Localtime = Universaltime = calendar:datetime()

              Converts  local  date  and  time  to  Universal Time Coordinated
              (UTC), if supported by the underlying OS. Otherwise  no  conver-
              sion is done and Localtime is returned. Example:

              > erlang:localtime_to_universaltime({{1996,11,6},{14,45,17}}).
              {{1996,11,6},{13,45,17}}

              Failure: badarg if Localtime denotes an invalid date and time.

       erlang:localtime_to_universaltime(Localtime, IsDst) ->
                                            Universaltime

              Types:

                 Localtime = Universaltime = calendar:datetime()
                 IsDst = true | false | undefined

              Converts local date and time to Universal Time Coordinated (UTC)
              as erlang:localtime_to_universaltime/1, but the  caller  decides
              if Daylight Saving Time is active.

              If  IsDst  == true, Localtime is during Daylight Saving Time, if
              IsDst == false it is not. If IsDst == undefined, the  underlying
              OS  can  guess,  which  is  the  same  as  calling erlang:local-
              time_to_universaltime(Localtime).

              Examples:

              > erlang:localtime_to_universaltime({{1996,11,6},{14,45,17}}, true).
              {{1996,11,6},{12,45,17}}
              > erlang:localtime_to_universaltime({{1996,11,6},{14,45,17}}, false).
              {{1996,11,6},{13,45,17}}
              > erlang:localtime_to_universaltime({{1996,11,6},{14,45,17}}, undefined).
              {{1996,11,6},{13,45,17}}

              Failure: badarg if Localtime denotes an invalid date and time.

       make_ref() -> reference()

              Returns a  unique reference. The reference is unique among  con-
              nected nodes.

          Warning:
              Known  issue:  When  a node is restarted multiple times with the
              same node name, references created on a newer node can  be  mis-
              taken  for  a  reference  created on an older node with the same
              node name.

       erlang:make_tuple(Arity, InitialValue) -> tuple()

              Types:

                 Arity = arity()
                 InitialValue = term()

              Creates a new tuple of the specified Arity, where  all  elements
              are InitialValue, for example:

              > erlang:make_tuple(4, []).
              {[],[],[],[]}

       erlang:make_tuple(Arity, DefaultValue, InitList) -> tuple()

              Types:

                 Arity = arity()
                 DefaultValue = term()
                 InitList = [{Position :: integer() >= 1, term()}]

              Creates  a tuple of size Arity, where each element has value De-
              faultValue, and then fills in values from  InitList.  Each  list
              element in InitList 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:

              > erlang:make_tuple(5, [], [{2,ignored},{5,zz},{2,aa}]).
              {[],aa,[],[],zz}

       map_get(Key, Map) -> Value

              Types:

                 Map = map()
                 Key = Value = any()

              Returns value Value associated with Key if Map contains Key.

              The call fails with a {badmap,Map} exception if  Map  is  not  a
              map,  or with a {badkey,Key} exception if no value is associated
              with Key.

              Example:

              > Key = 1337,
                Map = #{42 => value_two,1337 => "value one","a" => 1},
                map_get(Key,Map).
              "value one"

              Allowed in guard tests.

       map_size(Map) -> integer() >= 0

              Types:

                 Map = map()

              Returns an integer, which is the number of  key-value  pairs  in
              Map, for example:

              > map_size(#{a=>1, b=>2, c=>3}).
              3

              Allowed in guard tests.

       erlang:match_spec_test(MatchAgainst, MatchSpec, Type) ->
                                 TestResult

              Types:

                 MatchAgainst = [term()] | tuple()
                 MatchSpec = term()
                 Type = table | trace
                 TestResult =
                     {ok,   term(),   [return_trace],   [{error   |   warning,
                 string()}]} |
                     {error, [{error | warning, string()}]}

              Tests a match specification used in calls  to  ets:select/2  and
              erlang:trace_pattern/3. The function tests both a match specifi-
              cation for "syntactic" correctness and runs the match specifica-
              tion against the object. If the match specification contains er-
              rors, the tuple {error, Errors} is returned, where Errors  is  a
              list of natural language descriptions of what was wrong with the
              match specification.

              If Type is table, the object to match against is to 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 specification does not match the object
              tuple.

              If Type is trace, the object to match against is to be  a  list.
              The function returns {ok, Result, Flags, Warnings}, where Result
              is one of the following:

                * true if a trace message is to be emitted

                * false if a trace message is not to be emitted

                * The message term to be appended to the trace message

              Flags is a list containing all the trace flags  to  be  enabled,
              currently this is only return_trace.

              This  is a useful debugging and test tool, especially when writ-
              ing complicated match specifications.

              See also ets:test_ms/2.

       max(Term1, Term2) -> Maximum

              Types:

                 Term1 = Term2 = Maximum = term()

              Returns the largest of Term1 and Term2. If the terms are  equal,
              Term1 is returned.

       erlang:md5(Data) -> Digest

              Types:

                 Data = iodata()
                 Digest = binary()

              Computes  an  MD5  message digest from Data, where the length of
              the digest is 128 bits (16 bytes). Data is a binary or a list of
              small integers and binaries.

              For more information about MD5, see  RFC 1321 - The MD5 Message-
              Digest Algorithm.

          Warning:
              The MD5 Message-Digest Algorithm  is  not  considered  safe  for
              code-signing or software-integrity purposes.

       erlang:md5_final(Context) -> Digest

              Types:

                 Context = Digest = binary()

              Finishes  the  update of an MD5 Context and returns the computed
              MD5 message digest.

       erlang:md5_init() -> Context

              Types:

                 Context = binary()

              Creates an MD5 context, to be used in  the  following  calls  to
              md5_update/2.

       erlang:md5_update(Context, Data) -> NewContext

              Types:

                 Context = binary()
                 Data = iodata()
                 NewContext = binary()

              Update an MD5 Context with Data and returns a NewContext.

       erlang:memory() -> [{Type, Size}]

              Types:

                 Type = memory_type()
                 Size = integer() >= 0
                 memory_type() =
                     total | processes | processes_used | system | atom |
                     atom_used | binary | code | ets

              Returns  a  list with information about memory dynamically allo-
              cated by the Erlang emulator.  Each  list  element  is  a  tuple
              {Type,  Size}. The first element Type is an atom describing mem-
              ory type. The second element Size is the memory size in bytes.

              Memory types:

                total:
                  The total amount of memory currently allocated. This is  the
                  same as the sum of the memory size for processes and system.

                processes:
                  The  total  amount of memory currently allocated for the Er-
                  lang processes.

                processes_used:
                  The total amount of memory currently used by the Erlang pro-
                  cesses.  This  is  part of the memory presented as processes
                  memory.

                system:
                  The total amount of memory currently allocated for the  emu-
                  lator  that  is  not directly related to any Erlang process.
                  Memory presented as processes is not included in  this  mem-
                  ory.  instrument(3erl)  can  be  used to get a more detailed
                  breakdown of what memory is part of this type.

                atom:
                  The total amount of memory currently  allocated  for  atoms.
                  This  memory  is part of the memory presented as system mem-
                  ory.

                atom_used:
                  The total amount of memory currently used  for  atoms.  This
                  memory is part of the memory presented as atom memory.

                binary:
                  The total amount of memory currently allocated for binaries.
                  This memory is part of the memory presented as  system  mem-
                  ory.

                code:
                  The  total  amount  of memory currently allocated for Erlang
                  code. This memory is part of the memory presented as  system
                  memory.

                ets:
                  The  total  amount of memory currently allocated for ETS ta-
                  bles. This memory is part of the memory presented as  system
                  memory.

                low:
                  Only on 64-bit halfword emulator. The total amount of memory
                  allocated in low memory areas that are restricted to < 4 GB,
                  although the system can have more memory.

                  Can be removed in a future release of the halfword emulator.

                maximum:
                  The  maximum total amount of memory allocated since the emu-
                  lator was started. This tuple is only present when the  emu-
                  lator is run with instrumentation.

                  For information on how to run the emulator with instrumenta-
                  tion, see instrument(3erl) and/or erl(1).

          Note:
              The system value is not complete. Some allocated memory that  is
              to be part of this value is not.

              When  the emulator is run with instrumentation, the system value
              is more accurate, but memory directly allocated for malloc  (and
              friends)  is still not part of the system value. Direct calls to
              malloc are only done from OS-specific runtime libraries and per-
              haps  from  user-implemented  Erlang drivers that do not use the
              memory allocation functions in the driver interface.

              As the total value is the sum of processes and system, the error
              in system propagates to the total value.

              The different amounts of memory that are summed are not gathered
              atomically, which introduces an error in the result.

              The different values have the following relation to each  other.
              Values beginning with an uppercase letter is not part of the re-
              sult.

              total      = processes + system
              processes  = processes_used + ProcessesNotUsed
              system     = atom + binary + code + ets + OtherSystem
              atom       = atom_used + AtomNotUsed
              RealTotal  = processes + RealSystem
              RealSystem = system + MissedSystem

              More tuples in the returned list can be added in  a  future  re-
              lease.

          Note:
              The total value is supposed to be the total amount of memory dy-
              namically allocated by the emulator. Shared libraries, the  code
              of the emulator itself, and the emulator stacks are not supposed
              to be included. That is, the total value is not supposed  to  be
              equal to the total size of all pages mapped to the emulator.

              Also,  because of fragmentation and prereservation of memory ar-
              eas, 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.

          Note:
              As from ERTS 5.6.4, erlang:memory/0 requires that  all  erts_al-
              loc(3erl) allocators are enabled (default behavior).

              Failure:  notsup  if an erts_alloc(3erl) allocator has been dis-
              abled.

       erlang:memory(Type :: memory_type()) -> integer() >= 0

       erlang:memory(TypeList :: [memory_type()]) ->
                        [{memory_type(), integer() >= 0}]

              Types:

                 memory_type() =
                     total | processes | processes_used | system | atom |
                     atom_used | binary | code | ets

              Returns the memory size in bytes allocated for  memory  of  type
              Type.  The  argument  can  also  be  specified as a list of mem-
              ory_type() atoms, in which case a corresponding  list  of  {mem-
              ory_type(), Size :: integer >= 0} tuples is returned.

          Note:
              As  from  ERTS 5.6.4, erlang:memory/1 requires that all erts_al-
              loc(3erl) allocators are enabled (default behavior).

              Failures:

                badarg:
                   If Type is not one of the memory types listed  in  the  de-
                  scription of erlang:memory/0.

                badarg:
                   If maximum is passed as Type and the emulator is not run in
                  instrumented mode.

                notsup:
                   If an erts_alloc(3erl) allocator has been disabled.

              See also erlang:memory/0.

       min(Term1, Term2) -> Minimum

              Types:

                 Term1 = Term2 = Minimum = term()

              Returns the smallest of Term1 and Term2. If the terms are equal,
              Term1 is returned.

       module_loaded(Module) -> boolean()

              Types:

                 Module = module()

              Returns true if the module Module is loaded, otherwise false. It
              does not attempt to load the module.

          Warning:
              This BIF is intended for the code server (see code(3erl)) and is
              not to be used elsewhere.

       monitor(Type :: process, Item :: monitor_process_identifier()) ->
                  MonitorRef

       monitor(Type :: port, Item :: monitor_port_identifier()) ->
                  MonitorRef

       monitor(Type :: time_offset, Item :: clock_service) -> MonitorRef

              Types:

                 MonitorRef = reference()
                 registered_name() = atom()
                 registered_process_identifier() =
                     registered_name() | {registered_name(), node()}
                 monitor_process_identifier() =
                     pid() | registered_process_identifier()
                 monitor_port_identifier() = port() | registered_name()

              Sends a monitor request of type Type to the entity identified by
              Item. If the monitored entity does not exist or it changes moni-
              tored state, the caller of monitor/2 is notified by a message on
              the following format:

              {Tag, MonitorRef, Type, Object, Info}

          Note:
              The monitor request is an asynchronous signal. That is, it takes
              time before the signal reaches its destination.

              Type  can  be  one  of  the  following  atoms:  process, port or
              time_offset.

              A process or port monitor is triggered only once, after that  it
              is  removed  from  both monitoring process and the monitored en-
              tity. Monitors are fired when the monitored process or port ter-
              minates,  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 demonitor/1 is called.

              A process or port monitor by name resolves the RegisteredName to
              pid()  or  port()  only once at the moment of monitor instantia-
              tion, later changes to the name registration will not affect the
              existing monitor.

              When a process or port monitor is triggered, a 'DOWN' message is
              sent that has the following pattern:

              {'DOWN', MonitorRef, Type, Object, Info}

              In the monitor message MonitorRef and Type are the same  as  de-
              scribed earlier, and:

                Object:
                  The  monitored entity, which triggered the event. When moni-
                  toring a local process or port, Object will be equal to  the
                  pid()  or  port()  that was being monitored. When monitoring
                  process or port by name, Object  will  have  format  {Regis-
                  teredName,  Node} where RegisteredName is the name which has
                  been used with monitor/2 call and Node is  local  or  remote
                  node name (for ports monitored by name, Node is always local
                  node name).

                Info:
                  Either the exit reason of the process,  noproc  (process  or
                  port  did not exist at the time of monitor creation), or no-
                  connection (no connection to the node  where  the  monitored
                  process resides).

                Monitoring a process:
                  Creates  monitor  between  the  current  process and another
                  process identified by Item, which can be a pid()  (local  or
                  remote),  an atom RegisteredName or a tuple {RegisteredName,
                  Node} for a registered process, located elsewhere.

            Note:
                Before ERTS 10.0 (OTP 21.0), monitoring a process  could  fail
                with  badarg  if  the monitored process resided on a primitive
                node (such  as  erl_interface  or  jinterface),  where  remote
                process monitoring is not implemented.

                Now, such a call to monitor will instead succeed and a monitor
                is created. But the monitor will only  supervise  the  connec-
                tion.  That is, a {'DOWN', _, process, _, noconnection} is the
                only message that may be received, as the primitive node  have
                no way of reporting the status of the monitored process.

                Monitoring a port:
                  Creates monitor between the current process and a port iden-
                  tified by Item, which can be a port() (only local), an  atom
                  RegisteredName  or a tuple {RegisteredName, Node} for a reg-
                  istered port, located on this node. Note,  that  attempt  to
                  monitor a remote port will result in badarg.

                Monitoring a time_offset:
                  Monitors  changes  in  time  offset between Erlang monotonic
                  time and Erlang system time. One valid Item exists in combi-
                  nation with the time_offset Type, namely the atom clock_ser-
                  vice. Notice that the atom clock_service is not  the  regis-
                  tered  name of a process. In this case it serves as an iden-
                  tifier of the runtime system internal clock service at  cur-
                  rent runtime system instance.

                  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 finaliza-
                  tion of the time offset when the single time  warp  mode  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.

                  If  the  runtime system is in multi time warp mode, the time
                  offset is changed when the runtime system detects  that  the
                  OS  system  time  has changed. The runtime system does, how-
                  ever, 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  de-
                  tected  within  a  minute, but during heavy load it can take
                  longer time.

                  The monitor is not automatically removed after it  has  been
                  triggered.  That  is,  repeated  changes  of the time offset
                  trigger the monitor repeatedly.

                  When the monitor is triggered a 'CHANGE' message is sent  to
                  the monitoring process. A 'CHANGE' message has the following
                  pattern:

                {'CHANGE', MonitorRef, Type, Item, NewTimeOffset}

                  where MonitorRef, Type, and Item are the same  as  described
                  above, and NewTimeOffset is the new time offset.

                  When  the 'CHANGE' message has been received you are guaran-
                  teed not to retrieve the old time offset  when  calling  er-
                  lang:time_offset().  Notice  that you can observe the change
                  of the time offset when calling erlang:time_offset()  before
                  you get the 'CHANGE' message.

              Making  several calls to monitor/2 for the same Item and/or Type
              is not an error; it results in as  many  independent  monitoring
              instances.

              The  monitor  functionality is expected to be extended. That is,
              other Types and Items are expected to be supported in  a  future
              release.

          Note:
              If or when monitor/2 is extended, other possible values for Tag,
              Object, and Info in the monitor message will be introduced.

       monitor_node(Node, Flag) -> true

              Types:

                 Node = node()
                 Flag = boolean()

              Monitor the status of the node Node. If Flag is true, monitoring
              is turned on. If Flag is false, monitoring is turned off.

              Making  several  calls  to monitor_node(Node, true) for the same
              Node is not an error; it results in as many independent monitor-
              ing instances.

              If Node fails or does not exist, the message {nodedown, Node} is
              delivered to the process. If a process has  made  two  calls  to
              monitor_node(Node,  true) and Node terminates, two nodedown mes-
              sages are delivered to the process. If there is no connection to
              Node,  an  attempt is made to create one. If this fails, a node-
              down message is delivered.

              Nodes connected through hidden connections can be  monitored  as
              any other nodes.

              Failure: badarg if the local node is not alive.

       erlang:monitor_node(Node, Flag, Options) -> true

              Types:

                 Node = node()
                 Flag = boolean()
                 Options = [Option]
                 Option = allow_passive_connect

              Behaves  as monitor_node/2 except that it allows an extra option
              to be specified, namely allow_passive_connect. This  option  al-
              lows  the BIF to wait the normal network connection time-out for
              the monitored node to connect itself, even if it cannot  be  ac-
              tively  connected  from  this node (that is, it is blocked). The
              state where this can be useful can only be achieved by using the
              Kernel  option  dist_auto_connect  once.  If  that option is not
              used, option allow_passive_connect has no effect.

          Note:
              Option allow_passive_connect is used internally  and  is  seldom
              needed in applications where the network topology and the Kernel
              options in effect are known in advance.

              Failure: badarg if the local node is not  alive  or  the  option
              list is malformed.

       erlang:monotonic_time() -> integer()

              Returns  the  current Erlang monotonic time in native time unit.
              This is a monotonically increasing time since  some  unspecified
              point in time.

          Note:
              This  is  a   monotonically increasing time, but not a  strictly
              monotonically increasing time. That is, consecutive calls to er-
              lang:monotonic_time/0 can produce the same result.

              Different  runtime  system instances will use different unspeci-
              fied points in time as base for their Erlang  monotonic  clocks.
              That  is, it is pointless comparing monotonic times from differ-
              ent 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 posi-
              tive value), or the runtime  system  start  (time  at  start  is
              zero).  The  monotonic  time  at runtime system start can be re-
              trieved by calling erlang:system_info(start_time).

       erlang:monotonic_time(Unit) -> integer()

              Types:

                 Unit = time_unit()

              Returns the current Erlang monotonic  time  converted  into  the
              Unit passed as argument.

              Same     as     calling    erlang:convert_time_unit(erlang:mono-
              tonic_time(), native, Unit), however optimized for commonly used
              Units.

       erlang:nif_error(Reason) -> no_return()

              Types:

                 Reason = term()

              Works  exactly  like  error/1, but Dialyzer 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, Dialyzer does not generate false warnings.

       erlang:nif_error(Reason, Args) -> no_return()

              Types:

                 Reason = term()
                 Args = [term()]

              Works exactly like error/2, but Dialyzer 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, Dialyzer does not generate false warnings.

       node() -> Node

              Types:

                 Node = node()

              Returns  the  name  of the local node. If the node is not alive,
              nonode@nohost is returned instead.

              Allowed in guard tests.

       node(Arg) -> Node

              Types:

                 Arg = pid() | port() | reference()
                 Node = node()

              Returns the node where Arg originates.  Arg  can  be  a  process
              identifier,  a  reference,  or  a port. If the local node is not
              alive, nonode@nohost is returned.

              Allowed in guard tests.

       nodes() -> Nodes

              Types:

                 Nodes = [node()]

              Returns a list of all visible nodes in the  system,  except  the
              local node. Same as nodes(visible).

       nodes(Arg) -> Nodes

              Types:

                 Arg = NodeType | [NodeType]
                 NodeType = visible | hidden | connected | this | known
                 Nodes = [node()]

              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.

              NodeTypes:

                visible:
                  Nodes connected to this node through normal connections.

                hidden:
                  Nodes connected to this node through hidden connections.

                connected:
                  All nodes connected to this node.

                this:
                  This node.

                known:
                  Nodes  that are known to this node. That is, connected nodes
                  and nodes referred to by process identifiers,  port  identi-
                  fiers, and references located on this node. The set of known
                  nodes is garbage collected. Notice that this garbage collec-
                  tion  can  be delayed. For more information, see erlang:sys-
                  tem_info(delayed_node_table_gc).

              Some equalities:  [node()]  =  nodes(this),  nodes(connected)  =
              nodes([visible, hidden]), and nodes() = nodes(visible).

       now() -> Timestamp

              Types:

                 Timestamp = timestamp()
                 timestamp() =
                     {MegaSecs :: integer() >= 0,
                      Secs :: integer() >= 0,
                      MicroSecs :: integer() >= 0}

          Warning:
              This function is deprecated. Do not use it.

              For  more  information,  see section Time and Time Correction in
              the User's Guide. Specifically,  section   Dos  and  Dont's  de-
              scribes what to use instead of erlang:now/0.

              Returns  the  tuple  {MegaSecs,  Secs,  MicroSecs}, which is the
              elapsed time since 00:00 GMT, January 1, 1970  (zero  hour),  if
              provided  by  the  underlying  OS. Otherwise some other point in
              time is chosen. It is also guaranteed that the  following  calls
              to  this  BIF  return continuously increasing values. Hence, the
              return value from erlang:now/0 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.

              Can only be used to check the local time of day if the time-zone
              information of the underlying OS is properly configured.

       open_port(PortName, PortSettings) -> port()

              Types:

                 PortName =
                     {spawn, Command :: string() | binary()} |
                     {spawn_driver, Command :: string() | binary()} |
                     {spawn_executable, FileName :: file:name_all()} |
                     {fd, In :: integer() >= 0, Out :: integer() >= 0}
                 PortSettings = [Opt]
                 Opt =
                     {packet, N :: 1 | 2 | 4} |
                     stream |
                     {line, L :: integer() >= 0} |
                     {cd, Dir :: string() | binary()} |
                     {env,
                      Env ::
                          [{Name :: os:env_var_name(),
                            Val :: os:env_var_value() | false}]} |
                     {args, [string() | binary()]} |
                     {arg0, string() | binary()} |
                     exit_status  | use_stdio | nouse_stdio | stderr_to_stdout
                 |
                     in | out | binary | eof |
                     {parallelism, Boolean :: boolean()} |
                     hide |
                     {busy_limits_port,
                      {integer() >= 0, integer() >= 0} | disabled} |
                     {busy_limits_msgq,
                      {integer() >= 0, integer() >= 0} | disabled}

              Returns a port identifier as the result of opening a new  Erlang
              port. A port can be seen as an external Erlang process.

              The  name of the executable as well as the arguments specifed in
              cd, env, args, and arg0 are subject to Unicode filename transla-
              tion if the system is running in Unicode filename mode. To avoid
              translation or to force, for  example  UTF-8,  supply  the  exe-
              cutable  and/or  arguments  as a binary in the correct encoding.
              For details, see the module file(3erl),  the  function  file:na-
              tive_name_encoding/0  in Kernel, and the Using Unicode in Erlang
              User's Guide.

          Note:
              The characters in the name (if specified as a list) can only  be
              >  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.

              PortNames:

                {spawn, Command}:
                  Starts  an  external program. Command is the name of the ex-
                  ternal program to be run. Command runs  outside  the  Erlang
                  work  space unless an Erlang driver with the name Command is
                  found. If found, that driver is started. A  driver  runs  in
                  the  Erlang  work  space, which means that it is linked with
                  the Erlang runtime system.

                  For external programs, PATH 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 {spawn_executable,
                  Command} instead.

                {spawn_driver, Command}:
                  Works like {spawn, Command}, 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 badarg  er-
                  ror is raised.

                {spawn_executable, FileName}:
                  Works  like  {spawn,  FileName}, but only runs external exe-
                  cutables. FileName in its whole is used as the name  of  the
                  executable,  including  any  spaces.  If arguments are to be
                  passed, the PortSettings args and arg0 can be used.

                  The shell is usually not invoked to start the program, it is
                  executed  directly. PATH (or equivalent) is not searched. To
                  find a program in PATH to execute, use os:find_executable/1.

                  Only if a shell script or .bat file is executed, the  appro-
                  priate  command interpreter is invoked implicitly, but there
                  is still no  command-argument  expansion  or  implicit  PATH
                  search.

                  If  FileName  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 enoent is raised
                  when an attempt is made to run a program that is  not  found
                  and  eacces  is  raised  when the specified file is not exe-
                  cutable.

                {fd, In, Out}:
                  Allows an Erlang process to access any currently opened file
                  descriptors  used  by  Erlang. The file descriptor In can be
                  used for standard input, and the  file  descriptor  Out  for
                  standard  output. It is only used for various servers in the
                  Erlang OS (shell and user). Hence, its use is limited.

              PortSettings is a list of settings for the port. The valid  set-
              tings are as follows:

                {packet, N}:
                  Messages are preceded by their length, sent in N bytes, with
                  the most significant byte first. The valid values for N  are
                  1, 2, and 4.

                stream:
                  Output  messages are sent without packet lengths. A user-de-
                  fined protocol must be used between the Erlang  process  and
                  the external object.

                {line, L}:
                  Messages  are  delivered on a per line basis. Each line (de-
                  limited by the OS-dependent newline sequence)  is  delivered
                  in  a  single  message.  The  message  data format is {Flag,
                  Line}, where Flag is eol or noeol, and Line is the data  de-
                  livered (without the newline sequence).

                  L  specifies  the maximum line length in bytes. Lines longer
                  than this are delivered in more than one message, with  Flag
                  set to noeol for all but the last message. If end of file is
                  encountered anywhere else than immediately following a  new-
                  line sequence, the last line is also delivered with Flag set
                  to noeol. Otherwise lines are delivered  with  Flag  set  to
                  eol.

                  The  {packet,  N} and {line, L} settings are mutually exclu-
                  sive.

                {cd, Dir}:
                  Only valid for {spawn, Command} and {spawn_executable, File-
                  Name}.  The external program starts using Dir as its working
                  directory. Dir must be a string.

                {env, Env}:
                  Types:
                  Name = os:env_var_name()
                  Val = os:env_var_value() | false
                  Env = [{Name, Val}]

                  Only valid  for  {spawn,  Command},  and  {spawn_executable,
                  FileName}.  The  environment  of  the started process is ex-
                  tended using the environment specifications in Env.

                  Env is to be a list of tuples {Name, Val}, where Name is the
                  name  of an environment variable, and Val is the value it is
                  to have in the spawned port process. Both Name and Val  must
                  be  strings.  The  one exception is Val being the atom false
                  (in analogy with os:getenv/1, which removes the  environment
                  variable.

                  For  information about encoding requirements, see documenta-
                  tion of the types for Name and Val.

                {args, [ string() | binary() ]}:
                  Only valid for {spawn_executable,  FileName}  and  specifies
                  arguments to the executable. Each argument is specified as a
                  separate string and (on Unix) eventually ends up as one ele-
                  ment each in the argument vector. On other platforms, a sim-
                  ilar behavior is mimicked.

                  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 filelib:wildcard/1. Notice that even
                  if the program is a Unix  shell  script,  meaning  that  the
                  shell ultimately is invoked, wildcard expansion does not oc-
                  cur, and the script is provided  with  the  untouched  argu-
                  ments.  On  Windows,  wildcard expansion is always up to the
                  program itself, therefore this is not an issue.

                  The executable name (also known as argv[0])  is  not  to  be
                  specified  in this list. The proper executable name is auto-
                  matically used as argv[0], where applicable.

                  If you explicitly want to set the program name in the  argu-
                  ment vector, option arg0 can be used.

                {arg0, string() | binary()}:
                  Only  valid  for {spawn_executable, FileName} and explicitly
                  specifies the program name argument  when  running  an  exe-
                  cutable. This can in some circumstances, on some OSs, be de-
                  sirable. How the program responds to this is highly  system-
                  dependent and no specific effect is guaranteed.

                exit_status:
                  Only  valid for {spawn, Command}, where Command refers to an
                  external program, and for {spawn_executable, FileName}.

                  When the external process connected to  the  port  exits,  a
                  message  of  the form {Port,{exit_status,Status}} is sent to
                  the connected process, where Status 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+sig-
                  nal).

                  If  option  eof  is  specified  also,  the  messages eof and
                  exit_status appear in an unspecified order.

                  If the port program closes its stdout without  exiting,  op-
                  tion exit_status does not work.

                use_stdio:
                  Only valid for {spawn, Command} and {spawn_executable, File-
                  Name}. It allows the standard input  and  output  (file  de-
                  scriptors  0 and 1) of the spawned (Unix) process for commu-
                  nication with Erlang.

                nouse_stdio:
                  The opposite of use_stdio. It uses file descriptors 3 and  4
                  for communication with Erlang.

                stderr_to_stdout:
                  Affects  ports  to  external  programs. The executed program
                  gets its standard error file redirected to its standard out-
                  put  file. stderr_to_stdout and nouse_stdio are mutually ex-
                  clusive.

                overlapped_io:
                  Affects ports to external  programs  on  Windows  only.  The
                  standard  input and standard output handles of the port pro-
                  gram are, if this  option  is  supplied,  opened  with  flag
                  FILE_FLAG_OVERLAPPED,  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. On  all  other
                  platforms, this option is silently discarded.

                in:
                  The port can only be used for input.

                out:
                  The port can only be used for output.

                binary:
                  All  I/O  from the port is binary data objects as opposed to
                  lists of bytes.

                eof:
                  The port is not closed at the end of the file and  does  not
                  produce  an  exit  signal.  Instead,  it  remains open and a
                  {Port, eof} message is sent to the process holding the port.

                hide:
                  When running on Windows, suppresses creation of a  new  con-
                  sole window when spawning the port program. (This option has
                  no effect on other platforms.)

                {parallelism, Boolean}:

                  Sets scheduler hint for port parallelism. If  set  to  true,
                  the  virtual machine schedules port tasks; when doing so, it
                  improves parallelism in the system. If  set  to  false,  the
                  virtual machine tries to perform port tasks immediately, im-
                  proving latency at the expense of parallelism.  The  default
                  can  be  set at system startup by passing command-line argu-
                  ment +spp to erl(1).

                {busy_limits_port, {Low, High} | disabled}:
                  Sets limits that will be used for controlling the busy state
                  of the port.

                  When  the  ports  internal  output queue size becomes larger
                  than or equal to High bytes, it enters the busy state.  When
                  it  becomes  less  than  Low bytes it leaves the busy state.
                  When the port is in the busy state, processes  sending  com-
                  mands to it will be suspended until the port leaves the busy
                  state. Commands are in this context either  Port  !  {Owner,
                  {command, Data}} or port_command/[2,3].

                  The  Low limit is automatically adjusted to the same as High
                  if it is set larger then High. Valid range of values for Low
                  and High is [1, (1 bsl (8*erlang:system_info(wordsize)))-2].
                  If the atom disabled is passed, the port  will  never  enter
                  the busy state.

                  The defaults are Low = 4096 and High = 8192.

                  Note  that  this  option is only valid when spawning an exe-
                  cutable (port program) by opening the spawn driver and  when
                  opening the fd driver. This option will cause a failure with
                  a badarg exception when opening other drivers.

                {busy_limits_msgq, {Low, High} | disabled}:
                  Sets limits that will be used for controlling the busy state
                  of the port message queue.

                  When  the  ports  message  queue size becomes larger than or
                  equal to High bytes it enters the busy state.  When  it  be-
                  comes less than Low bytes it leaves the busy state. When the
                  port message queue is in the busy state,  processes  sending
                  commands  to  it  will  be  suspended until the port message
                  queue leaves the busy state. Commands are  in  this  context
                  either   Port   !  {Owner,  {command,  Data}}  or  port_com-
                  mand/[2,3].

                  The Low limit is automatically adjusted to the same as  High
                  if it is set larger then High. Valid range of values for Low
                  and High is [1, (1 bsl (8*erlang:system_info(wordsize)))-2].
                  If  the atom disabled is passed, the port message queue will
                  never enter the busy state.

                  Note that if the driver statically has disabled the  use  of
                  this  feature,  a  failure  with  a badarg exception will be
                  raised unless this option also is  set  to  disable  or  not
                  passed at all.

                  The  defaults  are  Low  =  4096  and High = 8192 unless the
                  driver itself does modifications of these values.

                  Note that the driver might fail if it also adjust these lim-
                  its by itself and you have disabled this feature.

                  The  spawn driver (used when spawning an executable) and the
                  fd driver do not disable this  feature  and  do  not  adjust
                  these limits by themselves.

                  For     more     information     see    the    documentation
                  erl_drv_busy_msgq_limits().

              Default is stream for all port types and use_stdio  for  spawned
              ports.

              Failure:  if  the  port  cannot  be  opened,  the exit reason is
              badarg, system_limit, or the POSIX error code that most  closely
              describes the error, or einval if no POSIX code is appropriate:

                badarg:
                  Bad input arguments to open_port.

                system_limit:
                  All available ports in the Erlang emulator are in use.

                enomem:
                  Not enough memory to create the port.

                eagain:
                  No more available OS processes.

                enametoolong:
                  Too long external command.

                emfile:
                  No  more available file descriptors (for the OS process that
                  the Erlang emulator runs in).

                enfile:
                  Full file table (for the entire OS).

                eacces:
                  Command specified in {spawn_executable,  Command}  does  not
                  point out an executable file.

                enoent:
                  FileName  specified in {spawn_executable, FileName} does not
                  point out an existing file.

              During use of a port opened using {spawn, Name},  {spawn_driver,
              Name},  or {spawn_executable, Name}, errors arising when sending
              messages to it are reported to the owning process using  signals
              of  the  form {'EXIT', Port, PosixCode}. For the possible values
              of PosixCode, see file(3erl).

              The maximum number of ports that can be open at  the  same  time
              can be configured by passing command-line flag +Q to erl(1).

       erlang:phash(Term, Range) -> Hash

              Types:

                 Term = term()
                 Range = Hash = integer() >= 1
                   Range = 1..2^32, Hash = 1..Range

              Portable hash function that gives the same hash for the same Er-
              lang term regardless of machine architecture  and  ERTS  version
              (the BIF was introduced in ERTS 4.9.1.1). The function returns a
              hash value for Term within the range 1..Range. The maximum value
              for Range is 2^32.

       erlang:phash2(Term) -> Hash

       erlang:phash2(Term, Range) -> Hash

              Types:

                 Term = term()
                 Range = integer() >= 1
                   1..2^32
                 Hash = integer() >= 0
                   0..Range-1

              Portable hash function that gives the same hash for the same Er-
              lang term regardless of machine architecture  and  ERTS  version
              (the  BIF  was  introduced  in ERTS 5.2). The function returns a
              hash value for Term within the  range  0..Range-1.  The  maximum
              value for Range is 2^32. When without argument Range, a value in
              the range 0..2^27-1 is returned.

              This BIF is always to be used for hashing terms. It  distributes
              small integers better than phash/2, and it is faster for bignums
              and binaries.

              Notice that the range 0..Range-1 is different from the range  of
              phash/2, which is 1..Range.

       pid_to_list(Pid) -> string()

              Types:

                 Pid = pid()

              Returns  a  string  corresponding  to the text representation of
              Pid.

       erlang:port_call(Port, Operation, Data) -> term()

              Types:

                 Port = port() | atom()
                 Operation = integer()
                 Data = term()

              Performs a synchronous call to a port. The meaning of  Operation
              and  Data  depends on the port, that is, on the port driver. Not
              all port drivers support this feature.

              Port is a port identifier, referring to a driver.

              Operation is an integer, which is passed on to the driver.

              Data is any Erlang term. This data is converted to  binary  term
              format and sent to the port.

              Returns a term from the driver. The meaning of the returned data
              also depends on the port driver.

              Failures:

                badarg:
                   If Port is not an identifier of an open port, or the regis-
                  tered  name of an open port. If the calling process was pre-
                  viously linked to the closed port, identified by  Port,  the
                  exit  signal from the port is guaranteed to be delivered be-
                  fore this badarg exception occurs.

                badarg:
                   If Operation does not fit in a 32-bit integer.

                badarg:
                   If the port driver does not support synchronous control op-
                  erations.

                badarg:
                  If the port driver so decides for any reason (probably some-
                  thing wrong with Operation or Data).

            Warning:
                Do not call port_call with an unknown Port identifier and  ex-
                pect badarg exception. Any undefined behavior is possible (in-
                cluding node crash) depending on how the  port  driver  inter-
                prets the supplied arguments.

       port_close(Port) -> true

              Types:

                 Port = port() | atom()

              Closes  an open port. Roughly the same as Port ! {self(), close}
              except for the error behavior (see  below),  being  synchronous,
              and  that  the  port  does  not  reply  with {Port, closed}. Any
              process can close a port with port_close/1, not  only  the  port
              owner  (the connected process). If the calling process is linked
              to the port identified by Port, the exit signal from the port is
              guaranteed to be delivered before port_close/1 returns.

              For comparison: Port ! {self(), close} only fails with badarg if
              Port does not refer to a port or a process. If Port is a  closed
              port,  nothing  happens. If Port is an open port and the calling
              process is the port owner, the port replies with {Port,  closed}
              when  all  buffers have been flushed and the port really closes.
              If the calling process is not the port  owner,  the  port  owner
              fails with badsig.

              Notice  that  any  process  can  close a port using Port ! {Por-
              tOwner, close} as if it itself was the port owner, but the reply
              always goes to the port owner.

              As from Erlang/OTP R16, Port ! {PortOwner, close} is truly asyn-
              chronous. Notice that this operation has always been  documented
              as  an  asynchronous operation, while the underlying implementa-
              tion has been synchronous. port_close/1 is however  still  fully
              synchronous because of its error behavior.

              Failure: badarg if Port 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 Port, the
              exit signal from the port is guaranteed to be  delivered  before
              this badarg exception occurs.

       port_command(Port, Data) -> true

              Types:

                 Port = port() | atom()
                 Data = iodata()

              Sends  data  to  a  port.  Same  as Port ! {PortOwner, {command,
              Data}} except for the error behavior and being synchronous  (see
              below). Any process can send data to a port with port_command/2,
              not only the port owner (the connected process).

              For comparison: Port ! {PortOwner, {command, Data}}  only  fails
              with  badarg  if  Port does not refer to a port or a process. If
              Port is a closed port, the data  message  disappears  without  a
              sound.  If  Port is open and the calling process is not the port
              owner, the port owner fails with badsig. The  port  owner  fails
              with badsig also if Data is an invalid I/O list.

              Notice  that  any  process can send to a port using Port ! {Por-
              tOwner, {command, Data}} as if it itself was the port owner.

              If the port is busy, the calling process is suspended until  the
              port is not busy any more.

              As  from  Erlang/OTP R16, Port ! {PortOwner, {command, Data}} is
              truly asynchronous. Notice that this operation has  always  been
              documented  as  an  asynchronous operation, while the underlying
              implementation has been synchronous. port_command/2  is  however
              still fully synchronous because of its error behavior.

              Failures:

                badarg:
                  If  Port is not an identifier of an open port, or the regis-
                  tered name of an open port. If the calling process was  pre-
                  viously  linked  to the closed port, identified by Port, the
                  exit signal from the port is guaranteed to be delivered  be-
                  fore this badarg exception occurs.

                badarg:
                  If Data is an invalid I/O list.

          Warning:
              Do  not  send data to an unknown port. Any undefined behavior is
              possible (including node crash) depending on how the port driver
              interprets the data.

       port_command(Port, Data, OptionList) -> boolean()

              Types:

                 Port = port() | atom()
                 Data = iodata()
                 Option = force | nosuspend
                 OptionList = [Option]

              Sends  data  to  a  port.  port_command(Port,  Data,  []) equals
              port_command(Port, Data).

              If the port command is aborted,  false  is  returned,  otherwise
              true.

              If  the port is busy, the calling process is suspended until the
              port is not busy anymore.

              Options:

                force:
                  The calling process is not suspended if the  port  is  busy,
                  instead  the  port command is forced through. The call fails
                  with a notsup exception if the driver of the port  does  not
                  support   this.   For  more  information,  see  driver  flag
                  ![CDATA[ERL_DRV_FLAG_SOFT_BUSY]].

                nosuspend:
                  The calling process is not suspended if the  port  is  busy,
                  instead the port command is aborted and false is returned.

          Note:
              More options can be added in a future release.

              Failures:

                badarg:
                   If Port is not an identifier of an open port, or the regis-
                  tered name of an open port. If the calling process was  pre-
                  viously  linked  to the closed port, identified by Port, the
                  exit signal from the port is guaranteed to be delivered  be-
                  fore this badarg exception occurs.

                badarg:
                   If Data is an invalid I/O list.

                badarg:
                   If OptionList is an invalid option list.

                notsup:
                   If option force has been passed, but the driver of the port
                  does not allow forcing through a busy port.

          Warning:
              Do not send data to an unknown port. Any undefined  behavior  is
              possible (including node crash) depending on how the port driver
              interprets the data.

       port_connect(Port, Pid) -> true

              Types:

                 Port = port() | atom()
                 Pid = pid()

              Sets the port owner (the connected port)  to  Pid.  Roughly  the
              same as Port ! {Owner, {connect, Pid}} except for the following:

                * The error behavior differs, see below.

                * The port does not reply with {Port,connected}.

                * port_connect/1 is synchronous, see below.

                * The new port owner gets linked to the port.

              The  old  port  owner stays linked to the port and must call un-
              link(Port) if this is not desired. Any process can set the  port
              owner to be any process with port_connect/2.

              For  comparison: Port ! {self(), {connect, Pid}} only fails with
              badarg if Port does not refer to a port or a process. If Port is
              a  closed port, nothing happens. If Port is an open port and the
              calling process is the port owner, the port replies with  {Port,
              connected} to the old port owner. Notice that the old port owner
              is still linked to the port, while the new is not. If Port is an
              open  port  and  the  calling process is not the port owner, the
              port owner fails with badsig. The port owner fails  with  badsig
              also if Pid is not an existing local process identifier.

              Notice  that  any  process  can  set the port owner using Port !
              {PortOwner, {connect, Pid}} as if it itself was the port  owner,
              but the reply always goes to the port owner.

              As  from  Erlang/OTP  R16, Port ! {PortOwner, {connect, Pid}} is
              truly asynchronous. Notice that this operation has  always  been
              documented  as  an  asynchronous operation, while the underlying
              implementation has been synchronous. port_connect/2  is  however
              still fully synchronous because of its error behavior.

              Failures:

                badarg:
                   If Port is not an identifier of an open port, or the regis-
                  tered name of an open port. If the calling process was  pre-
                  viously  linked  to the closed port, identified by Port, the
                  exit signal from the port is guaranteed to be delivered  be-
                  fore this badarg exception occurs.

                badarg:
                  If  the  process  identified by Pid is not an existing local
                  process.

       port_control(Port, Operation, Data) -> iodata() | binary()

              Types:

                 Port = port() | atom()
                 Operation = integer()
                 Data = iodata()

              Performs a synchronous control operation on a port. The  meaning
              of  Operation and Data depends on the port, that is, on the port
              driver. Not all port drivers support this control feature.

              Returns a list of integers in the range 0..255, or a binary, de-
              pending  on  the  port  driver. The meaning of the returned data
              also depends on the port driver.

              Failures:

                badarg:
                   If Port is not an open port or the registered  name  of  an
                  open port.

                badarg:
                   If Operation cannot fit in a 32-bit integer.

                badarg:
                   If the port driver does not support synchronous control op-
                  erations.

                badarg:
                   If the port driver so  decides  for  any  reason  (probably
                  something wrong with Operation or Data).

            Warning:
                Do not call port_control/3 with an unknown Port identifier and
                expect badarg exception. Any undefined  behavior  is  possible
                (including node crash) depending on how the port driver inter-
                prets the supplied arguments.

       erlang:port_info(Port) -> Result

              Types:

                 Port = port() | atom()
                 ResultItem =
                     {registered_name, RegisteredName :: atom()} |
                     {id, Index :: integer() >= 0} |
                     {connected, Pid :: pid()} |
                     {links, Pids :: [pid()]} |
                     {name, String :: string()} |
                     {input, Bytes :: integer() >= 0} |
                     {output, Bytes :: integer() >= 0} |
                     {os_pid, OsPid :: integer() >= 0 | undefined}
                 Result = [ResultItem] | undefined

              Returns a list containing tuples with information about Port, or
              undefined  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  deliv-
              ered before port_info/1 returns undefined.

              The result contains information about the following Items:

                * registered_name (if the port has a registered name)

                * id

                * connected

                * links

                * name

                * input

                * output

              For more information about the different Items, see port_info/2.

              Failure:  badarg  if  Port is not a local port identifier, or an
              atom.

       erlang:port_info(Port, Item :: connected) ->
                           {connected, Pid} | undefined

              Types:

                 Port = port() | atom()
                 Pid = pid()

              Pid is the process identifier of the process  connected  to  the
              port.

              If  the  port  identified  by Port is not open, undefined is re-
              turned. If the port is closed and the calling process was previ-
              ously linked to the port, the exit signal from the port is guar-
              anteed to be delivered before port_info/2 returns undefined.

              Failure: badarg if Port is not a local port  identifier,  or  an
              atom.

       erlang:port_info(Port, Item :: id) -> {id, Index} | undefined

              Types:

                 Port = port() | atom()
                 Index = integer() >= 0

              Index  is the internal index of the port. This index can be used
              to separate ports.

              If the port identified by Port is not  open,  undefined  is  re-
              turned. If the port is closed and the calling process was previ-
              ously linked to the port, the exit signal from the port is guar-
              anteed to be delivered before port_info/2 returns undefined.

              Failure:  badarg  if  Port is not a local port identifier, or an
              atom.

       erlang:port_info(Port, Item :: input) ->
                           {input, Bytes} | undefined

              Types:

                 Port = port() | atom()
                 Bytes = integer() >= 0

              Bytes is the total number of bytes read from the port.

              If the port identified by Port is not  open,  undefined  is  re-
              turned. If the port is closed and the calling process was previ-
              ously linked to the port, the exit signal from the port is guar-
              anteed to be delivered before port_info/2 returns undefined.

              Failure:  badarg  if  Port is not a local port identifier, or an
              atom.

       erlang:port_info(Port, Item :: links) -> {links, Pids} | undefined

              Types:

                 Port = port() | atom()
                 Pids = [pid()]

              Pids is a list of the process identifiers of the processes  that
              the port is linked to.

              If  the  port  identified  by Port is not open, undefined is re-
              turned. If the port is closed and the calling process was previ-
              ously linked to the port, the exit signal from the port is guar-
              anteed to be delivered before port_info/2 returns undefined.

              Failure: badarg if Port is not a local port  identifier,  or  an
              atom.

       erlang:port_info(Port, Item :: locking) ->
                           {locking, Locking} | undefined

              Types:

                 Port = port() | atom()
                 Locking = false | port_level | driver_level

              Locking is one of the following:

                * port_level (port-specific locking)

                * driver_level (driver-specific locking)

              Notice that these results are highly implementation-specific and
              can change in a future release.

              If the port identified by Port is not  open,  undefined  is  re-
              turned. If the port is closed and the calling process was previ-
              ously linked to the port, the exit signal from the port is guar-
              anteed to be delivered before port_info/2 returns undefined.

              Failure:  badarg  if  Port is not a local port identifier, or an
              atom.

       erlang:port_info(Port, Item :: memory) ->
                           {memory, Bytes} | undefined

              Types:

                 Port = port() | atom()
                 Bytes = integer() >= 0

              Bytes 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 Bytes.

              If the port identified by Port is not  open,  undefined  is  re-
              turned. If the port is closed and the calling process was previ-
              ously linked to the port, the exit signal from the port is guar-
              anteed to be delivered before port_info/2 returns undefined.

              Failure:  badarg  if  Port is not a local port identifier, or an
              atom.

       erlang:port_info(Port, Item :: monitors) ->
                           {monitors, Monitors} | undefined

              Types:

                 Port = port() | atom()
                 Monitors = [{process, pid()}]

              Monitors represent processes monitored by this port.

              If the port identified by Port is not  open,  undefined  is  re-
              turned. If the port is closed and the calling process was previ-
              ously linked to the port, the exit signal from the port is guar-
              anteed to be delivered before port_info/2 returns undefined.

              Failure:  badarg  if  Port is not a local port identifier, or an
              atom.

       erlang:port_info(Port, Item :: monitored_by) ->
                           {monitored_by, MonitoredBy} | undefined

              Types:

                 Port = port() | atom()
                 MonitoredBy = [pid()]

              Returns list of pids that are monitoring given port at  the  mo-
              ment.

              If  the  port  identified  by Port is not open, undefined is re-
              turned. If the port is closed and the calling process was previ-
              ously linked to the port, the exit signal from the port is guar-
              anteed to be delivered before port_info/2 returns undefined.

              Failure: badarg if Port is not a local port  identifier,  or  an
              atom.

       erlang:port_info(Port, Item :: name) -> {name, Name} | undefined

              Types:

                 Port = port() | atom()
                 Name = string()

              Name is the command name set by open_port/2.

              If  the  port  identified  by Port is not open, undefined is re-
              turned. If the port is closed and the calling process was previ-
              ously linked to the port, the exit signal from the port is guar-
              anteed to be delivered before port_info/2 returns undefined.

              Failure: badarg if Port is not a local port  identifier,  or  an
              atom.

       erlang:port_info(Port, Item :: os_pid) ->
                           {os_pid, OsPid} | undefined

              Types:

                 Port = port() | atom()
                 OsPid = integer() >= 0 | undefined

              OsPid is the process identifier (or equivalent) of an OS process
              created with open_port({spawn | spawn_executable, Command},  Op-
              tions). If the port is not the result of spawning an OS process,
              the value is undefined.

              If the port identified by Port is not  open,  undefined  is  re-
              turned. If the port is closed and the calling process was previ-
              ously linked to the port, the exit signal from the port is guar-
              anteed to be delivered before port_info/2 returns undefined.

              Failure:  badarg  if  Port is not a local port identifier, or an
              atom.

       erlang:port_info(Port, Item :: output) ->
                           {output, Bytes} | undefined

              Types:

                 Port = port() | atom()
                 Bytes = integer() >= 0

              Bytes is the total number of bytes written to the port from  Er-
              lang  processes  using port_command/2, port_command/3, or Port !
              {Owner, {command, Data}.

              If the port identified by Port is not  open,  undefined  is  re-
              turned. If the port is closed and the calling process was previ-
              ously linked to the port, the exit signal from the port is guar-
              anteed to be delivered before port_info/2 returns undefined.

              Failure:  badarg  if  Port is not a local port identifier, or an
              atom.

       erlang:port_info(Port, Item :: parallelism) ->
                           {parallelism, Boolean} | undefined

              Types:

                 Port = port() | atom()
                 Boolean = boolean()

              Boolean corresponds to the port parallelism hint  used  by  this
              port.   For   more   information,   see  option  parallelism  of
              open_port/2.

       erlang:port_info(Port, Item :: queue_size) ->
                           {queue_size, Bytes} | undefined

              Types:

                 Port = port() | atom()
                 Bytes = integer() >= 0

              Bytes is the total number of bytes queued by the port using  the
              ERTS driver queue implementation.

              If  the  port  identified  by Port is not open, undefined is re-
              turned. If the port is closed and the calling process was previ-
              ously linked to the port, the exit signal from the port is guar-
              anteed to be delivered before port_info/2 returns undefined.

              Failure: badarg if Port is not a local port  identifier,  or  an
              atom.

       erlang:port_info(Port, Item :: registered_name) ->
                           {registered_name, RegisteredName} |
                           [] | undefined

              Types:

                 Port = port() | atom()
                 RegisteredName = atom()

              RegisteredName  is  the registered name of the port. If the port
              has no registered name, [] is returned.

              If the port identified by Port is not  open,  undefined  is  re-
              turned. If the port is closed and the calling process was previ-
              ously linked to the port, the exit signal from the port is guar-
              anteed to be delivered before port_info/2 returns undefined.

              Failure:  badarg  if  Port is not a local port identifier, or an
              atom.

       port_to_list(Port) -> string()

              Types:

                 Port = port()

              Returns a string corresponding to the text representation of the
              port identifier Port.

       erlang:ports() -> [port()]

              Returns  a  list  of  port  identifiers corresponding to all the
              ports existing on the local node.

              Notice that an exiting port exists, but is not open.

       pre_loaded() -> [module()]

              Returns a list of Erlang modules that are preloaded in the  sys-
              tem. As all loading of code is done through the file system, the
              file system must have been loaded previously.  Hence,  at  least
              the module init must be preloaded.

       erlang:process_display(Pid, Type) -> true

              Types:

                 Pid = pid()
                 Type = backtrace

              Writes  information  about the local process Pid on standard er-
              ror. The only allowed value for  the  atom  Type  is  backtrace,
              which  shows  the contents of the call stack, including informa-
              tion about the call chain, with  the  current  function  printed
              first. The format of the output is not further defined.

       process_flag(Flag :: trap_exit, Boolean) -> OldBoolean

              Types:

                 Boolean = OldBoolean = boolean()

              When  trap_exit  is  set  to  true,  exit  signals arriving to a
              process are converted to {'EXIT', From, Reason} messages,  which
              can  be  received  as  ordinary messages. If trap_exit is set to
              false, the process exits if it receives  an  exit  signal  other
              than normal and the exit signal is propagated to its linked pro-
              cesses. Application processes are normally not to trap exits.

              Returns the old value of the flag.

              See also exit/2.

       process_flag(Flag :: error_handler, Module) -> OldModule

              Types:

                 Module = OldModule = atom()

              Used by a process to redefine the error  handler  for  undefined
              function calls and undefined registered processes. Inexperienced
              users are not to use this flag, as code auto-loading depends  on
              the correct operation of the error handling module.

              Returns the old value of the flag.

       process_flag(Flag :: min_heap_size, MinHeapSize) -> OldMinHeapSize

              Types:

                 MinHeapSize = OldMinHeapSize = integer() >= 0

              Changes the minimum heap size for the calling process.

              Returns the old value of the flag.

       process_flag(Flag :: min_bin_vheap_size, MinBinVHeapSize) ->
                       OldMinBinVHeapSize

              Types:

                 MinBinVHeapSize = OldMinBinVHeapSize = integer() >= 0

              Changes  the  minimum  binary  virtual heap size for the calling
              process.

              Returns the old value of the flag.

       process_flag(Flag :: max_heap_size, MaxHeapSize) -> OldMaxHeapSize

              Types:

                 MaxHeapSize = OldMaxHeapSize = max_heap_size()
                 max_heap_size() =
                     integer() >= 0 |
                     #{size => integer() >= 0,
                       kill => boolean(),
                       error_logger => boolean()}

              This flag sets the maximum heap size for the calling process. If
              MaxHeapSize  is  an  integer, the system default values for kill
              and error_logger are used.

                size:
                  The maximum size in words of the process. If  set  to  zero,
                  the  heap size limit is disabled. badarg is be thrown if the
                  value is smaller than min_heap_size. The size check is  only
                  done when a garbage collection is triggered.

                  size  is the entire heap of the process when garbage collec-
                  tion is triggered. This includes all generational heaps, the
                  process  stack, any  messages that are considered to be part
                  of the heap, and any extra memory that the garbage collector
                  needs during collection.

                  size   is   the   same   as   can  be  retrieved  using  er-
                  lang:process_info(Pid,  total_heap_size),   or   by   adding
                  heap_block_size,  old_heap_block_size and mbuf_size from er-
                  lang:process_info(Pid, garbage_collection_info).

                kill:
                  When set to true, the runtime system  sends  an  untrappable
                  exit  signal  with reason kill to the process if the maximum
                  heap size is reached. The garbage collection that  triggered
                  the kill is not completed, instead the process exits as soon
                  as possible. When set to false, no exit signal  is  sent  to
                  the process, instead it continues executing.

                  If  kill  is not defined in the map, the system default will
                  be used. The default system  default  is  true.  It  can  be
                  changed  by  either  option +hmaxk in erl(1), or erlang:sys-
                  tem_flag(max_heap_size, MaxHeapSize).

                error_logger:
                  When set to true, the runtime system logs an error event via
                  logger,  containing details about the process when the maxi-
                  mum heap size is reached. One log event is  sent  each  time
                  the limit is reached.

                  If  error_logger  is  not defined in the map, the system de-
                  fault is used. The default system default is true. It can be
                  changed  by  either  the  option  +hmaxel int erl(1), or er-
                  lang:system_flag(max_heap_size, MaxHeapSize).

              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 kill set to false and inspect the log
              events to see what the normal peak sizes of the processes in the
              system is and then tune the value accordingly.

       process_flag(Flag :: message_queue_data, MQD) -> OldMQD

              Types:

                 MQD = OldMQD = message_queue_data()
                 message_queue_data() = off_heap | on_heap

              This  flag  determines  how  messages  in  the message queue are
              stored, as follows:

                off_heap:
                  All messages in the message queue will be stored outside  of
                  the  process heap. This implies that no messages in the mes-
                  sage queue will be part  of  a  garbage  collection  of  the
                  process.

                on_heap:
                  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 ERTS
                  8.0.

              The default message_queue_data process  flag  is  determined  by
              command-line argument +hmqd in erl(1).

              If  the  process potentially can get many messages in its queue,
              you are advised to set the flag  to  off_heap.  This  because  a
              garbage collection with many messages placed on the heap can be-
              come extremely expensive  and  the  process  can  consume  large
              amounts  of memory. Performance of the actual message passing is
              however generally better when not using flag off_heap.

              When changing this flag messages will be moved.  This  work  has
              been  initiated  but  not  completed when this function call re-
              turns.

              Returns the old value of the flag.

       process_flag(Flag :: priority, Level) -> OldLevel

              Types:

                 Level = OldLevel = priority_level()
                 priority_level() = low | normal | high | max

              Sets the process priority. Level is an atom. Four priority  lev-
              els exist: low, normal, high, and max. Default is normal.

          Note:
              Priority  level  max  is reserved for internal use in the Erlang
              runtime system, and is not to be used by others.

              Internally in each priority level, processes are scheduled in  a
              round robin fashion.

              Execution  of  processes  on  priority normal and low are inter-
              leaved. Processes on priority low  are  selected  for  execution
              less frequently than processes on priority normal.

              When  runnable processes on priority high exist, no processes on
              priority low or normal are selected for execution.  Notice  how-
              ever  that  this does not mean that no processes on priority low
              or normal can run when processes are running on  priority  high.
              When using multiple schedulers, more processes can be running in
              parallel than processes on priority high. That is, a low  and  a
              high priority process can execute at the same time.

              When  runnable  processes on priority max exist, no processes on
              priority low, normal, or high are  selected  for  execution.  As
              with priority high, processes on lower priorities can execute in
              parallel with processes on priority max.

              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.

          Note:
              Do not depend on the scheduling to remain exactly as it  is  to-
              day.  Scheduling  is likely to be changed in a future release to
              use available processor cores better.

              There is no automatic mechanism for avoiding priority inversion,
              such  as  priority  inheritance or priority ceilings. When using
              priorities, take this into account and handle such scenarios  by
              yourself.

              Making calls from a high priority process into code that you has
              no control over can cause the high priority process to wait  for
              a  process  with lower priority. That is, effectively decreasing
              the priority of the high priority process during the call.  Even
              if  this  is  not the case with one version of the code that you
              have no control over, it can be the case in a future version  of
              it.  This  can,  for  example,  occur if a high priority process
              triggers code loading, as the code server runs on priority  nor-
              mal.

              Other priorities than normal are normally not needed. When other
              priorities are used, use them  with  care,  especially  priority
              high.  A  process  on  priority high is only to perform work for
              short periods. Busy looping for long periods in a high  priority
              process  causes  most  likely problems, as important OTP servers
              run on priority normal.

              Returns the old value of the flag.

       process_flag(Flag :: save_calls, N) -> OldN

              Types:

                 N = OldN = 0..10000

              N must be an integer in the interval 0..10000. If N  >  0,  call
              saving  is made active for the process. This means that informa-
              tion about the N most recent global function calls,  BIF  calls,
              sends,  and  receives  made  by the process are saved in a list,
              which can be retrieved  with  process_info(Pid,  last_calls).  A
              global  function call is one in which the module of the function
              is explicitly mentioned. Only a fixed amount of  information  is
              saved, as follows:

                * A tuple {Module, Function, Arity} for function calls

                * The  atoms  send,  'receive',  and timeout for sends and re-
                  ceives ('receive' when a message  is  received  and  timeout
                  when a receive times out)

              If  N = 0, call saving is disabled for the process, which is the
              default. Whenever the size of the call saving list is  set,  its
              contents are reset.

              Returns the old value of the flag.

       process_flag(Flag :: sensitive, Boolean) -> OldBoolean

              Types:

                 Boolean = OldBoolean = boolean()

              Sets  or  clears  flag sensitive for the current process. When a
              process   has   been   marked   as    sensitive    by    calling
              process_flag(sensitive,  true),  features  in the runtime system
              that can be used for examining the data or inner working of  the
              process are silently disabled.

              Features  that are disabled include (but are not limited to) the
              following:

                * Tracing. Trace flags can still be set for the  process,  but
                  no trace messages of any kind are generated. (If flag sensi-
                  tive is turned off, trace messages are  again  generated  if
                  any trace flags are set.)

                * Sequential tracing. The sequential trace token is propagated
                  as usual, but no sequential trace messages are generated.

              process_info/1,2 cannot be used to read out the message queue or
              the process dictionary (both are returned as empty lists).

              Stack back-traces cannot be displayed for the process.

              In  crash dumps, the stack, messages, and the process dictionary
              are omitted.

              If {save_calls,N} has been set  for  the  process,  no  function
              calls  are  saved to the call saving list. (The call saving list
              is not cleared. Also, send, receive,  and  time-out  events  are
              still added to the list.)

              Returns the old value of the flag.

       process_flag(Pid, Flag, Value) -> OldValue

              Types:

                 Pid = pid()
                 Flag = save_calls
                 Value = OldValue = integer() >= 0

              Sets  certain  flags  for the process Pid, in the same manner as
              process_flag/2. Returns the old value of  the  flag.  The  valid
              values   for  Flag  are  only  a  subset  of  those  allowed  in
              process_flag/2, namely save_calls.

              Failure: badarg if Pid is not a local process.

       process_info(Pid) -> Info

              Types:

                 Pid = pid()
                 Info = [InfoTuple] | undefined
                 InfoTuple = process_info_result_item()
                 process_info_result_item() =
                     {backtrace, Bin :: binary()} |
                     {binary,
                      BinInfo ::
                          [{integer() >= 0,
                            integer() >= 0,
                            integer() >= 0}]} |
                     {catchlevel, CatchLevel :: integer() >= 0} |
                     {current_function,
                      {Module :: module(), Function :: atom(), Arity :: arity()} |
                      undefined} |
                     {current_location,
                      {Module :: module(),
                       Function :: atom(),
                       Arity :: arity(),
                       Location ::
                           [{file, Filename :: string()} |
                            {line, Line :: integer() >= 1}]}} |
                     {current_stacktrace, Stack :: [stack_item()]} |
                     {dictionary, Dictionary :: [{Key :: term(), Value :: term()}]} |
                     {error_handler, Module :: module()} |
                     {garbage_collection, GCInfo :: [{atom(), integer() >= 0}]} |
                     {garbage_collection_info,
                      GCInfo :: [{atom(), integer() >= 0}]} |
                     {group_leader, GroupLeader :: pid()} |
                     {heap_size, Size :: integer() >= 0} |
                     {initial_call, mfa()} |
                     {links, PidsAndPorts :: [pid() | port()]} |
                     {last_calls, false | (Calls :: [mfa()])} |
                     {memory, Size :: integer() >= 0} |
                     {message_queue_len, MessageQueueLen :: integer() >= 0} |
                     {messages, MessageQueue :: [term()]} |
                     {min_heap_size, MinHeapSize :: integer() >= 0} |
                     {min_bin_vheap_size, MinBinVHeapSize :: integer() >= 0} |
                     {max_heap_size, MaxHeapSize :: max_heap_size()} |
                     {monitored_by,
                      MonitoredBy :: [pid() | port() | nif_resource()]} |
                     {monitors,
                      Monitors ::
                          [{process | port,
                            Pid ::
                                pid() |
                                port() |
                                {RegName :: atom(), Node :: node()}}]} |
                     {message_queue_data, MQD :: message_queue_data()} |
                     {priority, Level :: priority_level()} |
                     {reductions, Number :: integer() >= 0} |
                     {registered_name, [] | (Atom :: atom())} |
                     {sequential_trace_token,
                      [] | (SequentialTraceToken :: term())} |
                     {stack_size, Size :: integer() >= 0} |
                     {status,
                      Status ::
                          exiting | garbage_collecting | waiting | running |
                          runnable | suspended} |
                     {suspending,
                      SuspendeeList ::
                          [{Suspendee :: pid(),
                            ActiveSuspendCount :: integer() >= 0,
                            OutstandingSuspendCount :: integer() >= 0}]} |
                     {total_heap_size, Size :: integer() >= 0} |
                     {trace, InternalTraceFlags :: integer() >= 0} |
                     {trap_exit, Boolean :: boolean()}
                 priority_level() = low | normal | high | max
                 stack_item() =
                     {Module :: module(),
                      Function :: atom(),
                      Arity :: arity() | (Args :: [term()]),
                      Location ::
                          [{file, Filename :: string()} |
                           {line, Line :: integer() >= 1}]}
                 max_heap_size() =
                     integer() >= 0 |
                     #{size => integer() >= 0,
                       kill => boolean(),
                       error_logger => boolean()}
                 message_queue_data() = off_heap | on_heap

              Returns a list containing InfoTuples with miscellaneous informa-
              tion  about  the  process identified by Pid, or undefined if the
              process is not alive.

              The order of the InfoTuples is undefined and all InfoTuples  are
              not  mandatory. The InfoTuples part of the result can be changed
              without prior notice.

              The InfoTuples with the following items are part of the result:

                * current_function

                * initial_call

                * status

                * message_queue_len

                * links

                * dictionary

                * trap_exit

                * error_handler

                * priority

                * group_leader

                * total_heap_size

                * heap_size

                * stack_size

                * reductions

                * garbage_collection

              If the process identified by Pid has a registered name, also  an
              InfoTuple with item registered_name is included.

              For information about specific InfoTuples, see process_info/2.

          Warning:
              This BIF is intended for debugging only. For all other purposes,
              use process_info/2.

              Failure: badarg if Pid is not a local process.

       process_info(Pid, Item) -> InfoTuple | [] | undefined

       process_info(Pid, ItemList) -> InfoTupleList | [] | undefined

              Types:

                 Pid = pid()
                 ItemList = [Item]
                 Item = process_info_item()
                 InfoTupleList = [InfoTuple]
                 InfoTuple = process_info_result_item()
                 process_info_item() =
                     backtrace | binary | catchlevel | current_function |
                     current_location | current_stacktrace | dictionary |
                     error_handler | garbage_collection | garbage_collection_info |
                     group_leader | heap_size | initial_call | links | last_calls |
                     memory | message_queue_len | messages | min_heap_size |
                     min_bin_vheap_size | monitored_by | monitors |
                     message_queue_data | priority | reductions | registered_name |
                     sequential_trace_token | stack_size | status | suspending |
                     total_heap_size | trace | trap_exit
                 process_info_result_item() =
                     {backtrace, Bin :: binary()} |
                     {binary,
                      BinInfo ::
                          [{integer() >= 0,
                            integer() >= 0,
                            integer() >= 0}]} |
                     {catchlevel, CatchLevel :: integer() >= 0} |
                     {current_function,
                      {Module :: module(), Function :: atom(), Arity :: arity()} |
                      undefined} |
                     {current_location,
                      {Module :: module(),
                       Function :: atom(),
                       Arity :: arity(),
                       Location ::
                           [{file, Filename :: string()} |
                            {line, Line :: integer() >= 1}]}} |
                     {current_stacktrace, Stack :: [stack_item()]} |
                     {dictionary, Dictionary :: [{Key :: term(), Value :: term()}]} |
                     {error_handler, Module :: module()} |
                     {garbage_collection, GCInfo :: [{atom(), integer() >= 0}]} |
                     {garbage_collection_info,
                      GCInfo :: [{atom(), integer() >= 0}]} |
                     {group_leader, GroupLeader :: pid()} |
                     {heap_size, Size :: integer() >= 0} |
                     {initial_call, mfa()} |
                     {links, PidsAndPorts :: [pid() | port()]} |
                     {last_calls, false | (Calls :: [mfa()])} |
                     {memory, Size :: integer() >= 0} |
                     {message_queue_len, MessageQueueLen :: integer() >= 0} |
                     {messages, MessageQueue :: [term()]} |
                     {min_heap_size, MinHeapSize :: integer() >= 0} |
                     {min_bin_vheap_size, MinBinVHeapSize :: integer() >= 0} |
                     {max_heap_size, MaxHeapSize :: max_heap_size()} |
                     {monitored_by,
                      MonitoredBy :: [pid() | port() | nif_resource()]} |
                     {monitors,
                      Monitors ::
                          [{process | port,
                            Pid ::
                                pid() |
                                port() |
                                {RegName :: atom(), Node :: node()}}]} |
                     {message_queue_data, MQD :: message_queue_data()} |
                     {priority, Level :: priority_level()} |
                     {reductions, Number :: integer() >= 0} |
                     {registered_name, [] | (Atom :: atom())} |
                     {sequential_trace_token,
                      [] | (SequentialTraceToken :: term())} |
                     {stack_size, Size :: integer() >= 0} |
                     {status,
                      Status ::
                          exiting | garbage_collecting | waiting | running |
                          runnable | suspended} |
                     {suspending,
                      SuspendeeList ::
                          [{Suspendee :: pid(),
                            ActiveSuspendCount :: integer() >= 0,
                            OutstandingSuspendCount :: integer() >= 0}]} |
                     {total_heap_size, Size :: integer() >= 0} |
                     {trace, InternalTraceFlags :: integer() >= 0} |
                     {trap_exit, Boolean :: boolean()}
                 stack_item() =
                     {Module :: module(),
                      Function :: atom(),
                      Arity :: arity() | (Args :: [term()]),
                      Location ::
                          [{file, Filename :: string()} |
                           {line, Line :: integer() >= 1}]}
                 priority_level() = low | normal | high | max
                 max_heap_size() =
                     integer() >= 0 |
                     #{size => integer() >= 0,
                       kill => boolean(),
                       error_logger => boolean()}
                 message_queue_data() = off_heap | on_heap

              Returns information about the  process  identified  by  Pid,  as
              specified  by Item or ItemList. Returns undefined if the process
              is not alive.

              If the process is alive and a single Item is specified, the  re-
              turned  value  is  the  corresponding InfoTuple, unless Item =:=
              registered_name and the process has no registered name. In  this
              case,  []  is returned. This strange behavior is because of his-
              torical reasons, and is kept for backward compatibility.

              If ItemList is specified, the result is InfoTupleList. The Info-
              Tuples  in  InfoTupleList  are  included  with the corresponding
              Items in the same order as the Items were included in  ItemList.
              Valid Items can be included multiple times in ItemList.

          Note:
              If  registered_name  is  part of ItemList and the process has no
              name registered, a {registered_name, []}, InfoTuple will be  in-
              cluded  in the resulting InfoTupleList. This behavior is differ-
              ent when a single Item =:=  registered_name  is  specified,  and
              when process_info/1 is used.

              Valid InfoTuples with corresponding Items:

                {backtrace, Bin}:
                  Binary  Bin contains the same information as the output from
                  erlang:process_display(Pid, backtrace). Use binary_to_list/1
                  to obtain the string of characters from the binary.

                {binary, BinInfo}:
                  BinInfo is a list containing miscellaneous information about
                  binaries on the heap of this process. This InfoTuple can  be
                  changed  or removed without prior notice. In the current im-
                  plementation BinInfo is a list of tuples.  The  tuples  con-
                  tain; BinaryId, BinarySize, BinaryRefcCount.

                  The  message  queue  is on the heap depending on the process
                  flag message_queue_data.

                {catchlevel, CatchLevel}:
                  CatchLevel is the number of currently active catches in this
                  process.  This  InfoTuple  can be changed or removed without
                  prior notice.

                {current_function, {Module, Function, Arity} | undefined}:
                  Module, Function, Arity is the current function call of  the
                  process.  The value undefined can be returned if the process
                  is currently executing native compiled code.

                {current_location, {Module, Function, Arity, Location}}:
                  Module, Function, Arity is the current function call of  the
                  process. Location is a list of two-tuples describing the lo-
                  cation in the source code.

                {current_stacktrace, Stack}:
                  Returns the current call stack  back-trace  (stacktrace)  of
                  the  process.  The stack has the same format as in the catch
                  part of a try. See The call-stack back  trace  (stacktrace).
                  The  depth  of  the stacktrace is truncated according to the
                  backtrace_depth system flag setting.

                {dictionary, Dictionary}:
                  Dictionary is the process dictionary.

                {error_handler, Module}:
                  Module is the error handler module used by the process  (for
                  undefined function calls, for example).

                {garbage_collection, GCInfo}:
                  GCInfo  is a list containing miscellaneous information about
                  garbage collection for this process. The content  of  GCInfo
                  can be changed without prior notice.

                {garbage_collection_info, GCInfo}:
                  GCInfo  is a list containing miscellaneous detailed informa-
                  tion about garbage collection for this process. The  content
                  of  GCInfo  can be changed without prior notice. For details
                  about the meaning of each item, see  gc_minor_start  in  er-
                  lang:trace/3.

                {group_leader, GroupLeader}:
                  GroupLeader is the group leader for the I/O of the process.

                {heap_size, Size}:
                  Size 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.

                {initial_call, {Module, Function, Arity}}:
                  Module, Function, Arity is the initial  function  call  with
                  which the process was spawned.

                {links, PidsAndPorts}:
                  PidsAndPorts is a list of process identifiers and port iden-
                  tifiers, with processes or ports to which the process has  a
                  link.

                {last_calls, false|Calls}:
                  The  value  is  false  if  call saving is not active for the
                  process (see process_flag/3). If call saving  is  active,  a
                  list  is returned, in which the last element is the most re-
                  cent called.

                {memory, Size}:

                  Size is the size in bytes of the process. This includes call
                  stack, heap, and internal structures.

                {message_queue_len, MessageQueueLen}:
                  MessageQueueLen  is  the number of messages currently in the
                  message queue of the process. This is the length of the list
                  MessageQueue  returned as the information item messages (see
                  below).

                {messages, MessageQueue}:
                  MessageQueue is a list of the messages to the process, which
                  have not yet been processed.

                {min_heap_size, MinHeapSize}:
                  MinHeapSize is the minimum heap size for the process.

                {min_bin_vheap_size, MinBinVHeapSize}:
                  MinBinVHeapSize  is the minimum binary virtual heap size for
                  the process.

                {monitored_by, MonitoredBy}:
                  A list of identifiers for all the processes, ports  and  NIF
                  resources, that are monitoring the process.

                {monitors, Monitors}:
                  A  list  of  monitors (started by monitor/2) that are active
                  for the process. For a local process  monitor  or  a  remote
                  process  monitor  by a process identifier, the list consists
                  of:

                  {process, Pid}:
                    Process is monitored by pid.

                  {process, {RegName, Node}}:
                    Local or remote process is monitored by name.

                  {port, PortId}:
                    Local port is monitored by port id.

                  {port, {RegName, Node}}:
                    Local port is monitored by name. Please note, that  remote
                    port  monitors  are  not supported, so Node will always be
                    the local node name.

                {message_queue_data, MQD}:
                  Returns   the   current   state   of   process   flag   mes-
                  sage_queue_data. MQD is either off_heap or on_heap. For more
                  information,  see  the  documentation  of  process_flag(mes-
                  sage_queue_data, MQD).

                {priority, Level}:
                  Level  is  the  current  priority level for the process. For
                  more information on priorities,  see  process_flag(priority,
                  Level).

                {reductions, Number}:
                  Number is the number of reductions executed by the process.

                {registered_name, Atom}:
                  Atom  is  the registered process name. If the process has no
                  registered name, this tuple is not present in the list.

                {sequential_trace_token, [] | SequentialTraceToken}:
                  SequentialTraceToken is the sequential trace token  for  the
                  process.  This  InfoTuple  can be changed or removed without
                  prior notice.

                {stack_size, Size}:
                  Size is the stack size, in words, of the process.

                {status, Status}:
                  Status is the status of the process and is one of  the  fol-
                  lowing:

                  * exiting

                  * garbage_collecting

                  * waiting (for a message)

                  * running

                  * runnable (ready to run, but another process is running)

                  * suspended  (suspended  on  a "busy" port or by the BIF er-
                    lang:suspend_process/1,2)

                {suspending, SuspendeeList}:
                  SuspendeeList is a list of  {Suspendee,  ActiveSuspendCount,
                  OutstandingSuspendCount}  tuples.  Suspendee  is the process
                  identifier of a process that has been, or  is  to  be,  sus-
                  pended  by the process identified by Pid through the BIF er-
                  lang:suspend_process/2 or erlang:suspend_process/1.

                  ActiveSuspendCount is the number of times Suspendee has been
                  suspended  by  Pid. OutstandingSuspendCount is the number of
                  not yet completed suspend requests sent by Pid, that is:

                  * If ActiveSuspendCount =/= 0, Suspendee is currently in the
                    suspended state.

                  * If  OutstandingSuspendCount  =/= 0, option asynchronous of
                    erlang:suspend_process/2 has been used and  the  suspendee
                    has not yet been suspended by Pid.

                  Notice  that  ActiveSuspendCount and OutstandingSuspendCount
                  are not the total suspend count on Suspendee, only the parts
                  contributed by Pid.

                {total_heap_size, Size}:
                  Size  is  the total size, in words, of all heap fragments of
                  the process. This includes the process stack and  any  unre-
                  ceived messages that are considered to be part of the heap.

                {trace, InternalTraceFlags}:
                  InternalTraceFlags  is  an integer representing the internal
                  trace flag for this process. This InfoTuple can  be  changed
                  or removed without prior notice.

                {trap_exit, Boolean}:
                  Boolean  is true if the process is trapping exits, otherwise
                  false.

              Notice that not all implementations support all these Items.

              Failures:

                badarg:
                  If Pid is not a local process.

                badarg:
                  If Item is an invalid item.

       processes() -> [pid()]

              Returns a list of process identifiers corresponding to  all  the
              processes currently existing on the local node.

              Notice  that  an  exiting process exists, but is not alive. That
              is, is_process_alive/1 returns false for an exiting process, but
              its  process identifier is part of the result returned from pro-
              cesses/0.

              Example:

              > processes().
              [<0.0.0>,<0.2.0>,<0.4.0>,<0.5.0>,<0.7.0>,<0.8.0>]

       purge_module(Module) -> true

              Types:

                 Module = atom()

              Removes  old  code  for  Module.  Before  this  BIF   is   used,
              check_process_code/2is  to  be called to check that no processes
              execute old code in the module.

          Warning:
              This BIF is intended for the code server (see code(3erl)) and is
              not to be used elsewhere.

          Note:
              As  from  ERTS 8.0 (Erlang/OTP 19), any lingering processes that
              still execute the old code is killed by this function.  In  ear-
              lier  versions,  such  incorrect use could cause much more fatal
              failures, like emulator crash.

              Failure: badarg if there is no old code for Module.

       put(Key, Val) -> term()

              Types:

                 Key = Val = term()

              Adds a new Key to the process dictionary,  associated  with  the
              value  Val,  and returns undefined. If Key exists, the old value
              is deleted and replaced by Val, and the function returns the old
              value. Example:

              > X = put(name, walrus), Y = put(name, carpenter),
              Z = get(name),
              {X, Y, Z}.
              {undefined,walrus,carpenter}

          Note:
              The  values  stored  when put is evaluated within the scope of a
              catch are not retracted if a throw is evaluated, or if an  error
              occurs.

       erlang:raise(Class, Reason, Stacktrace) -> no_return()

              Types:

                 Class = error | exit | throw
                 Reason = term()
                 Stacktrace = raise_stacktrace()
                 raise_stacktrace() =
                     [{module(), atom(), arity() | [term()]} |
                      {function(), [term()]}] |
                     [{module(), atom(), arity() | [term()], [{atom(), term()}]} |
                      {function(), [term()], [{atom(), term()}]}]

              Stops  the execution of the calling process with an exception of
              the specified class, reason, and call  stack  backtrace  (stack-
              trace).

              Class  is  error,  exit,  or  throw.  So, if it were not for the
              stacktrace, erlang:raise(Class, Reason, Stacktrace)  is  equiva-
              lent to erlang:Class(Reason).

              Reason  is  any  term.  Stacktrace  is  a  list as returned from
              get_stacktrace(), that is, a list of four-tuples {Module,  Func-
              tion,  Arity  |  Args,  Location}, where Module and Function are
              atoms, and the third element is an integer arity or an  argument
              list.  The stacktrace can also contain {Fun, Args, Location} tu-
              ples, where Fun is a local fun and Args is an argument list.

              Element Location at the end is optional. Omitting it is  equiva-
              lent to specifying an empty list.

              The stacktrace is used as the exception stacktrace for the call-
              ing process; it is truncated to the current  maximum  stacktrace
              depth.

              As  evaluating this function causes the process to terminate, it
              has no return value unless the arguments are invalid,  in  which
              case  the  function returns the error reason badarg. If you want
              to be sure not to return, you can call error(erlang:raise(Class,
              Reason, Stacktrace)) and hope to distinguish exceptions later.

       erlang:read_timer(TimerRef) -> Result

              Types:

                 TimerRef = reference()
                 Time = integer() >= 0
                 Result = Time | false

              Reads   the   state   of  a  timer.  The  same  as  calling  er-
              lang:read_timer(TimerRef, []).

       erlang:read_timer(TimerRef, Options) -> Result | ok

              Types:

                 TimerRef = reference()
                 Async = boolean()
                 Option = {async, Async}
                 Options = [Option]
                 Time = integer() >= 0
                 Result = Time | false

              Reads the state of a timer that has been created by  either  er-
              lang:start_timer  or  erlang:send_after. TimerRef identifies the
              timer, and was returned by the BIF that created the timer.

              Options:

                {async, Async}:
                  Asynchronous request for state information.  Async  defaults
                  to  false,  which  causes the operation to be performed syn-
                  chronously. In this case, the  Result  is  returned  by  er-
                  lang:read_timer. When Async is true, erlang:read_timer sends
                  an asynchronous request for the  state  information  to  the
                  timer service that manages the timer, and then returns ok. A
                  message on the format {read_timer, TimerRef, Result} is sent
                  to  the  caller  of erlang:read_timer when the operation has
                  been processed.

              More Options can be added in the future.

              If Result is an integer, it represents the time in  milliseconds
              left until the timer expires.

              If  Result is false, a timer corresponding to TimerRef could not
              be found. This because the timer had expired, or been  canceled,
              or  because  TimerRef 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.

          Note:
              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
              {async,  true}.  If  using  option  {async,  false}, the calling
              process is blocked until the operation has been performed.

              See  also  erlang:send_after/4,  erlang:start_timer/4,  and  er-
              lang:cancel_timer/2.

       ref_to_list(Ref) -> string()

              Types:

                 Ref = reference()

              Returns  a  string  corresponding  to the text representation of
              Ref.

          Warning:
              This BIF is intended for debugging and is not to be used in  ap-
              plication programs.

       register(RegName, PidOrPort) -> true

              Types:

                 RegName = atom()
                 PidOrPort = port() | pid()

              Associates the name RegName with a process identifier (pid) or a
              port identifier. RegName, which must be an atom, can be used in-
              stead  of the pid or port identifier in send operator (RegName !
              Message). Example:

              > register(db, Pid).
              true

              Failures:

                badarg:
                  If PidOrPort is not an existing local process or port.

                badarg:
                  If RegName is already in use.

                badarg:
                  If the process or port is already registered (already has  a
                  name).

                badarg:
                  If RegName is the atom undefined.

       registered() -> [RegName]

              Types:

                 RegName = atom()

              Returns  a  list of names that have been registered using regis-
              ter/2, for example:

              > registered().
              [code_server, file_server, init, user, my_db]

       erlang:resume_process(Suspendee) -> true

              Types:

                 Suspendee = pid()

              Decreases the suspend count on the process  identified  by  Sus-
              pendee.  Suspendee  is previously to have been suspended through
              erlang:suspend_process/2  or  erlang:suspend_process/1  by   the
              process  calling erlang:resume_process(Suspendee). When the sus-
              pend count on Suspendee reaches zero, Suspendee is resumed, that
              is,  its  state  is changed from suspended into the state it had
              before it was suspended.

          Warning:
              This BIF is intended for debugging only.

              Failures:

                badarg:
                   If Suspendee is not a process identifier.

                badarg:
                   If the process calling erlang:resume_process/1 had not pre-
                  viously  increased  the suspend count on the process identi-
                  fied by Suspendee.

                badarg:
                   If the process identified by Suspendee is not alive.

       round(Number) -> integer()

              Types:

                 Number = number()

              Returns an integer by rounding Number, for example:

              round(5.5).
              6

              Allowed in guard tests.

       self() -> pid()

              Returns the process identifier of the calling process, for exam-
              ple:

              > self().
              <0.26.0>

              Allowed in guard tests.

       erlang:send(Dest, Msg) -> Msg

              Types:

                 Dest = dst()
                 Msg = term()
                 dst() =
                     pid() |
                     port() |
                     (RegName :: atom()) |
                     {RegName :: atom(), Node :: node()}

              Sends  a  message and returns Msg. This is the same as using the
              send operator: Dest ! Msg.

              Dest can be a remote or  local  process  identifier,  a  (local)
              port,  a locally registered name, or a tuple {RegName, Node} for
              a registered name at another node.

              The function fails with a badarg run-time error if  Dest  is  an
              atom  name,  but  this  name is not registered. This is the only
              case when send fails for an  unreachable  destination  Dest  (of
              correct type).

       erlang:send(Dest, Msg, Options) -> Res

              Types:

                 Dest = dst()
                 Msg = term()
                 Options = [nosuspend | noconnect]
                 Res = ok | nosuspend | noconnect
                 dst() =
                     pid() |
                     port() |
                     (RegName :: atom()) |
                     {RegName :: atom(), Node :: node()}

              Either sends a message and returns ok, or does not send the mes-
              sage but returns something else (see below). Otherwise the  same
              as  erlang:send/2.  For  more detailed explanation and warnings,
              see erlang:send_nosuspend/2,3.

              Options:

                nosuspend:
                  If the sender would have to be suspended to do the send, no-
                  suspend is returned instead.

                noconnect:
                   If  the destination node would have to be auto-connected to
                  do the send, noconnect is returned instead.

          Warning:
              As with erlang:send_nosuspend/2,3: use with extreme care.

       erlang:send_after(Time, Dest, Msg) -> TimerRef

              Types:

                 Time = integer() >= 0
                 Dest = pid() | atom()
                 Msg = term()
                 TimerRef = reference()

              Starts a timer.  The  same  as  calling  erlang:send_after(Time,
              Dest, Msg, []).

       erlang:send_after(Time, Dest, Msg, Options) -> TimerRef

              Types:

                 Time = integer()
                 Dest = pid() | atom()
                 Msg = term()
                 Options = [Option]
                 Abs = boolean()
                 Option = {abs, Abs}
                 TimerRef = reference()

              Starts  a timer. When the timer expires, the message Msg is sent
              to the process identified by Dest. Apart from the format of  the
              time-out   message,   this   function   works   exactly  as  er-
              lang:start_timer/4.

       erlang:send_nosuspend(Dest, Msg) -> boolean()

              Types:

                 Dest = dst()
                 Msg = term()
                 dst() =
                     pid() |
                     port() |
                     (RegName :: atom()) |
                     {RegName :: atom(), Node :: node()}

              The same as erlang:send(Dest,  Msg,  [nosuspend]),  but  returns
              true  if  the  message was sent and false if the message was not
              sent because the sender would have had to be suspended.

              This function is intended for send operations to  an  unreliable
              remote  node without ever blocking the sending (Erlang) process.
              If the connection to the remote node (usually not a real  Erlang
              node, but a node written in C or Java) is overloaded, this func-
              tion does not send the message and returns false.

              The same occurs if Dest refers to a local port that is busy. For
              all  other  destinations (allowed for the ordinary send operator
              '!'), this function sends the message and returns true.

              This function is only to be used in rare circumstances  where  a
              process  communicates with Erlang nodes that can disappear with-
              out any trace, causing the TCP buffers and the drivers queue  to
              be over-full before the node is shut down (because of tick time-
              outs) by net_kernel. The normal reaction to take when  this  oc-
              curs is some kind of premature shutdown of the other node.

              Notice  that  ignoring the return value from this function would
              result in an unreliable message passing, which is  contradictory
              to the Erlang programming model. The message is not sent if this
              function returns false.

              In many systems, transient states of overloaded queues are  nor-
              mal. Although this function returns false does not mean that the
              other node is guaranteed to be non-responsive,  it  could  be  a
              temporary  overload. Also, a return value of true does only mean
              that the message can be sent on the (TCP) channel without block-
              ing; the message is not guaranteed to arrive at the remote node.
              For a disconnected non-responsive node, the return value is true
              (mimics  the  behavior of operator !). The expected behavior and
              the actions to take when the function returns false are applica-
              tion- and hardware-specific.

          Warning:
              Use with extreme care.

       erlang:send_nosuspend(Dest, Msg, Options) -> boolean()

              Types:

                 Dest = dst()
                 Msg = term()
                 Options = [noconnect]
                 dst() =
                     pid() |
                     port() |
                     (RegName :: atom()) |
                     {RegName :: atom(), Node :: node()}

              The  same  as erlang:send(Dest, Msg, [nosuspend | Options]), but
              with a Boolean return value.

              This function behaves like erlang:send_nosuspend/2, but takes  a
              third  parameter,  a  list of options. The only option is nocon-
              nect, which makes the function return false if the  remote  node
              is  not currently reachable by the local node. The normal behav-
              ior is to try to connect  to  the  node,  which  can  stall  the
              process during a short period. The use of option noconnect makes
              it possible to be sure not to get the slightest delay when send-
              ing to a remote process. This is especially useful when communi-
              cating with nodes that expect to always be the  connecting  part
              (that is, nodes written in C or Java).

              Whenever the function returns false (either when a suspend would
              occur or when noconnect was specified and the node was  not  al-
              ready  connected),  the  message  is guaranteed not to have been
              sent.

          Warning:
              Use with extreme care.

       erlang:set_cookie(Node, Cookie) -> true

              Types:

                 Node = node()
                 Cookie = atom()

              Sets the magic cookie of Node to the atom Cookie. If Node is the
              local  node,  the function also sets the cookie of all other un-
              known nodes to Cookie (see section  Distributed  Erlang  in  the
              Erlang Reference Manual in System Documentation).

              Failure: function_clause if the local node is not alive.

       setelement(Index, Tuple1, Value) -> Tuple2

              Types:

                 Index = integer() >= 1
                   1..tuple_size(Tuple1
                 Tuple1 = Tuple2 = tuple()
                 Value = term()

              Returns  a tuple that is a copy of argument Tuple1 with the ele-
              ment specified by integer argument Index (the first  element  is
              the  element with index 1) replaced by argument Value, for exam-
              ple:

              > setelement(2, {10, green, bottles}, red).
              {10,red,bottles}

       size(Item) -> integer() >= 0

              Types:

                 Item = tuple() | binary()

              Returns the number of elements in a tuple or the number of bytes
              in a binary or bitstring, for example:

              > size({morni, mulle, bwange}).
              3
              > size(<<11, 22, 33>>).
              3

              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 down.

              Allowed in guard tests.

              See also tuple_size/1, byte_size/1, and bit_size/1.

       spawn(Fun) -> pid()

              Types:

                 Fun = function()

              Returns  the  process identifier of a new process started by the
              application of Fun to the empty list [].  Otherwise  works  like
              spawn/3.

       spawn(Node, Fun) -> pid()

              Types:

                 Node = node()
                 Fun = function()

              Returns  the  process identifier of a new process started by the
              application of Fun to the empty list [] on Node.  If  Node  does
              not  exist,  a  useless  pid  is  returned. Otherwise works like
              spawn/3.

       spawn(Module, Function, Args) -> pid()

              Types:

                 Module = module()
                 Function = atom()
                 Args = [term()]

              Returns the process identifier of a new process started  by  the
              application of Module:Function to Args.

              error_handler:undefined_function(Module,   Function,   Args)  is
              evaluated by the new process if Module:Function/Arity  does  not
              exist (where Arity is the length of Args). The error handler can
              be redefined (see process_flag/2).  If  error_handler  is  unde-
              fined,  or  the user has redefined the default error_handler and
              its replacement is undefined, a failure with  reason  undef  oc-
              curs.

              Example:

              > spawn(speed, regulator, [high_speed, thin_cut]).
              <0.13.1>

       spawn(Node, Module, Function, Args) -> pid()

              Types:

                 Node = node()
                 Module = module()
                 Function = atom()
                 Args = [term()]

              Returns the process identifier (pid) of a new process started by
              the application of Module:Function to Args on Node. If Node does
              not  exist,  a  useless  pid  is  returned. Otherwise works like
              spawn/3.

       spawn_link(Fun) -> pid()

              Types:

                 Fun = function()

              Returns the process identifier of a new process started  by  the
              application  of  Fun to the empty list []. A link is created be-
              tween the calling process and the new process, atomically.  Oth-
              erwise works like spawn/3.

       spawn_link(Node, Fun) -> pid()

              Types:

                 Node = node()
                 Fun = function()

              Returns the process identifier (pid) of a new process started by
              the application of Fun to the empty list [] on Node. A  link  is
              created  between the calling process and the new process, atomi-
              cally. If Node does not exist, a useless pid is returned and  an
              exit  signal  with  reason  noconnection  is sent to the calling
              process. Otherwise works like spawn/3.

       spawn_link(Module, Function, Args) -> pid()

              Types:

                 Module = module()
                 Function = atom()
                 Args = [term()]

              Returns the process identifier of a new process started  by  the
              application  of  Module:Function  to Args. A link is created be-
              tween the calling process and the new process, atomically.  Oth-
              erwise works like spawn/3.

       spawn_link(Node, Module, Function, Args) -> pid()

              Types:

                 Node = node()
                 Module = module()
                 Function = atom()
                 Args = [term()]

              Returns the process identifier (pid) of a new process started by
              the application of Module:Function to Args on Node.  A  link  is
              created  between the calling process and the new process, atomi-
              cally. If Node does not exist, a useless pid is returned and  an
              exit  signal  with  reason  noconnection  is sent to the calling
              process. Otherwise works like spawn/3.

       spawn_monitor(Fun) -> {pid(), reference()}

              Types:

                 Fun = function()

              Returns the process identifier of a new process, started by  the
              application  of  Fun to the empty list [], and a reference for a
              monitor  created  to  the  new  process.  Otherwise  works  like
              spawn/3.

       spawn_monitor(Node, Fun) -> {pid(), reference()}

              Types:

                 Node = node()
                 Fun = function()

              Returns  the process identifier of a new process, started by the
              application of Fun to the empty list [] on the node Node, and  a
              reference  for  a  monitor created to the new process. Otherwise
              works like spawn/3.

              If the node identified by  Node  does  not  support  distributed
              spawn_monitor(), the call will fail with a notsup exception.

       spawn_monitor(Module, Function, Args) -> {pid(), reference()}

              Types:

                 Module = module()
                 Function = atom()
                 Args = [term()]

              A  new  process is started by the application of Module:Function
              to Args. The process is monitored at the same time. Returns  the
              process  identifier  and  a reference for the monitor. Otherwise
              works like spawn/3.

       spawn_monitor(Node, Module, Function, Args) ->
                        {pid(), reference()}

              Types:

                 Node = node()
                 Module = module()
                 Function = atom()
                 Args = [term()]

              A new process is started by the application  of  Module:Function
              to  Args  on the node Node. The process is monitored at the same
              time. Returns the process identifier and  a  reference  for  the
              monitor. Otherwise works like spawn/3.

              If  the  node  identified  by  Node does not support distributed
              spawn_monitor(), the call will fail with a notsup exception.

       spawn_opt(Fun, Options) -> pid() | {pid(), reference()}

              Types:

                 Fun = function()
                 Options = [spawn_opt_option()]
                 priority_level() = low | normal | high | max
                 max_heap_size() =
                     integer() >= 0 |
                     #{size => integer() >= 0,
                       kill => boolean(),
                       error_logger => boolean()}
                 message_queue_data() = off_heap | on_heap
                 spawn_opt_option() =
                     link | monitor |
                     {priority, Level :: priority_level()} |
                     {fullsweep_after, Number :: integer() >= 0} |
                     {min_heap_size, Size :: integer() >= 0} |
                     {min_bin_vheap_size, VSize :: integer() >= 0} |
                     {max_heap_size, Size :: max_heap_size()} |
                     {message_queue_data, MQD :: message_queue_data()}

              Returns the process identifier (pid) of a new process started by
              the  application  of  Fun  to the empty list []. Otherwise works
              like spawn_opt/4.

              If option monitor is specified, the  newly  created  process  is
              monitored,  and  both  the pid and reference for the monitor are
              returned.

       spawn_opt(Node, Fun, Options) -> pid() | {pid(), reference()}

              Types:

                 Node = node()
                 Fun = function()
                 Options = [monitor | link | OtherOption]
                 OtherOption = term()

              Returns the process identifier (pid) of a new process started by
              the  application  of  Fun  to the empty list [] on Node. If Node
              does not exist, a useless pid is returned. Otherwise works  like
              spawn_opt/4.

              Valid  options depends on what options are supported by the node
              identified by Node. A description of valid Options for the local
              node of current OTP version can be found in the documentation of
              spawn_opt/4.

       spawn_opt(Module, Function, Args, Options) ->
                    pid() | {pid(), reference()}

              Types:

                 Module = module()
                 Function = atom()
                 Args = [term()]
                 Options = [spawn_opt_option()]
                 priority_level() = low | normal | high | max
                 max_heap_size() =
                     integer() >= 0 |
                     #{size => integer() >= 0,
                       kill => boolean(),
                       error_logger => boolean()}
                 message_queue_data() = off_heap | on_heap
                 spawn_opt_option() =
                     link | monitor |
                     {priority, Level :: priority_level()} |
                     {fullsweep_after, Number :: integer() >= 0} |
                     {min_heap_size, Size :: integer() >= 0} |
                     {min_bin_vheap_size, VSize :: integer() >= 0} |
                     {max_heap_size, Size :: max_heap_size()} |
                     {message_queue_data, MQD :: message_queue_data()}

              Works as spawn/3, except that an extra option list is  specified
              when creating the process.

              If  option  monitor  is  specified, the newly created process is
              monitored, and both the pid and reference for  the  monitor  are
              returned.

              Options:

                link:
                  Sets a link to the parent process (like spawn_link/3 does).

                monitor:
                  Monitors the new process (like monitor/2 does).

                {priority, Level}:
                  Sets  the priority of the new process. Equivalent to execut-
                  ing process_flag(priority, Level) 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 process_flag(priority,
                  Level).

                {fullsweep_after, Number}:
                  Useful only for performance tuning. Do not use  this  option
                  unless  you  know that there is problem with execution times
                  or memory consumption, and ensure that the  option  improves
                  matters.

                  The  Erlang  runtime system uses a generational garbage col-
                  lection scheme, using an "old heap" for data that  has  sur-
                  vived at least one garbage collection. When there is no more
                  room on the old heap,  a  fullsweep  garbage  collection  is
                  done.

                  Option fullsweep_after makes it possible to specify the max-
                  imum number of generational  collections  before  forcing  a
                  fullsweep,  even  if  there is room on the old heap. Setting
                  the number to zero disables  the  general  collection  algo-
                  rithm,  that  is,  all  live data is copied at every garbage
                  collection.

                  A few cases when it can be useful to change fullsweep_after:

                  * If binaries that are no longer used are to be thrown  away
                    as soon as possible. (Set Number to zero.)

                  * 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 Number to
                    a suitable value, such as 10 or 20.

                  * In embedded systems with a limited amount of  RAM  and  no
                    virtual  memory, you might want to preserve memory by set-
                    ting Number to zero. (The value can be set  globally,  see
                    erlang:system_flag/2.)

                {min_heap_size, Size}:
                  Useful  only  for performance tuning. Do not use this option
                  unless you know that there is problem with  execution  times
                  or  memory  consumption, and ensure that the option improves
                  matters.

                  Gives a minimum heap size,  in  words.  Setting  this  value
                  higher  than  the system default can speed up some processes
                  because less garbage collection is done. However, setting  a
                  too high value can waste memory and slow down the system be-
                  cause of worse data locality.  Therefore,  use  this  option
                  only  for fine-tuning an application and to measure the exe-
                  cution time with various Size values.

                {min_bin_vheap_size, VSize}:
                  Useful only for performance tuning. Do not use  this  option
                  unless  you  know that there is problem with execution times
                  or memory consumption, and ensure that the  option  improves
                  matters.

                  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. However,
                  setting a too high value can waste  memory.  Therefore,  use
                  this  option only for fine-tuning an application and to mea-
                  sure the execution time with various VSize values.

                {max_heap_size, Size}:
                  Sets   the   max_heap_size   process   flag.   The   default
                  max_heap_size  is  determined by command-line argument +hmax
                  in erl(1). For more information, see  the  documentation  of
                  process_flag(max_heap_size, Size).

                {message_queue_data, MQD}:
                  Sets  the  state of the message_queue_data process flag. MQD
                  is to be  either  off_heap  or  on_heap.  The  default  mes-
                  sage_queue_data  process  flag is determined by command-line
                  argument +hmqd in erl(1). For more information, see the doc-
                  umentation of process_flag(message_queue_data, MQD).

       spawn_opt(Node, Module, Function, Args, Options) ->
                    pid() | {pid(), reference()}

              Types:

                 Node = node()
                 Module = module()
                 Function = atom()
                 Args = [term()]
                 Options = [monitor | link | OtherOption]
                 OtherOption = term()

              Returns the process identifier (pid) of a new process started by
              the application of Module:Function to Args on Node. If Node does
              not  exist,  a  useless  pid  is  returned. Otherwise works like
              spawn_opt/4.

              Valid options depends on what options are supported by the  node
              identified by Node. A description of valid Options for the local
              node of current OTP version can be found in the documentation of
              spawn_opt/4.

       spawn_request(Fun) -> ReqId

              Types:

                 Fun = function()
                 ReqId = reference()

              The  same  as  the call spawn_request(node(),Fun,[]). That is, a
              spawn request on the local node with no options.

       spawn_request(Fun, Options) -> ReqId

              Types:

                 Fun = function()
                 Option =
                     {reply_tag, ReplyTag} | {reply,  Reply}  |  spawn_opt_op-
                 tion()
                 ReplyTag = term()
                 Reply = yes | no | error_only | success_only
                 Options = [Option]
                 ReqId = reference()

              The same as the call spawn_request(node(),Fun,Options). That is,
              a spawn request on the local node.

       spawn_request(Node, Fun) -> ReqId

              Types:

                 Node = node()
                 Fun = function()
                 ReqId = reference()

              The same as the  call  spawn_request(Node,Fun,[]).  That  is,  a
              spawn request with no options.

       spawn_request(Node, Fun, Options) -> ReqId

              Types:

                 Node = node()
                 Fun = function()
                 Options = [Option]
                 Option =
                     monitor | link |
                     {reply_tag, ReplyTag} |
                     {reply, Reply} |
                     OtherOption
                 ReplyTag = term()
                 Reply = yes | no | error_only | success_only
                 OtherOption = term()
                 ReqId = reference()

              The  same  as spawn_request(Node,erlang,apply,[Fun,[]],Options).
              That is, a spawn request using the fun Fun of arity zero as  en-
              try point.

              This function will fail with a badarg exception if:

                * Node is not an atom.

                * Fun is not a fun of arity zero.

                * Options is not a proper list of terms.

       spawn_request(Module, Function, Args) -> ReqId

              Types:

                 Module = module()
                 Function = atom()
                 Args = [term()]
                 ReqId = reference()

              The   same   as   the   call   spawn_request(node(),Module,Func-
              tion,Args,[]). That is, a spawn request on the local  node  with
              no options.

       spawn_request(Node, Module, Function, Args) -> ReqId

              Types:

                 Node = node()
                 Module = module()
                 Function = atom()
                 Args = [term()]
                 ReqId = reference()

              The    same    as   the   call   spawn_request(Node,Module,Func-
              tion,Args,[]). That is, a spawn request with no options.

       spawn_request(Module, Function, Args, Options) -> ReqId

              Types:

                 Module = module()
                 Function = atom()
                 Args = [term()]
                 Option =
                     {reply_tag, ReplyTag} | {reply,  Reply}  |  spawn_opt_op-
                 tion()
                 ReplyTag = term()
                 Reply = yes | no | error_only | success_only
                 Options = [Option]
                 ReqId = reference()

              The   same   as   the   call   spawn_request(node(),Module,Func-
              tion,Args,Options). That is, a spawn request on the local node.

       spawn_request(Node, Module, Function, Args, Options) -> ReqId

              Types:

                 Node = node()
                 Module = module()
                 Function = atom()
                 Args = [term()]
                 Options = [Option]
                 Option =
                     monitor | link |
                     {reply_tag, ReplyTag} |
                     {reply, Reply} |
                     OtherOption
                 ReplyTag = term()
                 Reply = yes | no | error_only | success_only
                 OtherOption = term()
                 ReqId = reference()

              Asynchronously send a spawn request. Returns a  request  identi-
              fier ReqId.

              If the spawn operation succeeds, a new process is created on the
              node identified by Node. When a spawn  operation  succeeds,  the
              caller  will by default be sent a message on the form {ReplyTag,
              ReqId, ok, Pid} where Pid is the process identifier of the newly
              created process. Such a message is referred to as a success mes-
              sage  below in  the  text.  ReplyTag  is  by  default  the  atom
              spawn_reply unless modified by the {reply_tag, ReplyTag} option.
              The new process is started by the application of Module:Function
              to Args.

              The  spawn  operation  fails either if creation of a new process
              failed or if the spawn operation was interrupted by a connection
              failure.  When  a  spawn operation fails, the caller will by de-
              fault be sent a message on the  form  {ReplyTag,  ReqId,  error,
              Reason}  where Reason is the error reason. Such a message is re-
              ferred to as an error message  below in the text. Currently  the
              following spawn error Reasons are defined, but other reasons can
              appear at any time without prior notice:

                badopt:
                  An invalid Option was passed as argument. Note that  differ-
                  ent runtime systems may support different options.

                notsup:
                  The  node  identified  by Node does not support spawn opera-
                  tions issued by spawn_request().

                noconnection:
                  Failure to set up a connection to  the  node  identified  by
                  Node  or  the  connection  to  that node was lost during the
                  spawn operation. In the case  the  connection  was  lost,  a
                  process may or may not have been created.

                system_limit:
                  Could not create a new process due to that some system limit
                  was reached. Typically the process table was full.

              Valid Options:

                monitor:
                  In the absence of spawn operation failures, atomically  sets
                  up  a  monitor  to the newly created process. That is, as if
                  the calling process had called monitor(process,  Pid)  where
                  Pid  is the process identifier of the newly created process.
                  The ReqId returned by spawn_request() is also used as  moni-
                  tor  reference  as  if it was returned from monitor(process,
                  Pid).

                  The monitor will not be activated for  the  calling  process
                  until the spawn operation has succeeded. The monitor can not
                  be demonitored before the operation has succeeded. A  'DOWN'
                  message  for  the corresponding monitor is guaranteed not to
                  be delivered before a success message  that  corresponds  to
                  the spawn operation. If the spawn operation fails, no 'DOWN'
                  message will be delivered.

                  If the connection between the nodes involved  in  the  spawn
                  operation  is lost during the spawn operation, the spawn op-
                  eration will fail with an error reason  of  noconnection.  A
                  new process may or may not have been created.

                link:
                  In absence of spawn operation failures, atomically sets up a
                  link between the  calling  process  and  the  newly  created
                  process.  That  is,  as  if  the  calling process had called
                  link(Pid) where Pid is the process identifier of  the  newly
                  created process.

                  The link will not be activated for the calling process until
                  the spawn operation has succeeded. The link can not  be  re-
                  moved before the operation has succeeded. An exit signal due
                  to the link is guaranteed not to be delivered before a  suc-
                  cess  message   that  corresponds to the spawn operation. If
                  the spawn operation fails, no exit signal due  to  the  link
                  will be delivered to the caller of spawn_request().

                  If  the  connection  between the nodes involved in the spawn
                  operation is lost during the spawn operation, the spawn  op-
                  eration  will  fail  with an error reason of noconnection. A
                  new process may or may not have been created. If it has been
                  created,  it  will  be delivered an exit signal with an exit
                  reason of noconnection.

                {reply, Reply}:
                  Valid Reply values:

                  yes:
                    A spawn reply message will be sent to the  caller  regard-
                    less of whether the operation succeeds or not. If the call
                    to spawn_request() returns without  raising  an  exception
                    and  the reply option is set to yes, the caller is guaran-
                    teed to be delivered either a success message  or an error
                    message . The reply option is by default set to yes.

                  no:
                    No spawn reply message will be sent to the caller when the
                    spawn operation completes. This regardless of whether  the
                    operation succeeds or not.

                  error_only:
                    No  spawn  reply message will be sent to the caller if the
                    spawn operation succeeds, but an error  message   will  be
                    sent to the caller if the operation fails.

                  success_only:
                    No  spawn  reply message will be sent to the caller if the
                    spawn operation fails, but a success message  will be sent
                    to the caller if the operation succeeds.

                {reply_tag, ReplyTag}:
                  Sets  the  reply  tag to ReplyTag in the reply message. That
                  is, in the success  or error  message that is  sent  to  the
                  caller  due to the spawn operation. The default reply tag is
                  the atom spawn_reply.

                OtherOption:
                  Other valid options depends on what options are supported by
                  the  node  identified  by Node. A description of other valid
                  Options for the local node of current  OTP  version  can  be
                  found in the documentation of spawn_opt/4.

              This function will fail with a badarg exception if:

                * Node is not an atom.

                * Module is not an atom.

                * Function is not an atom.

                * Args is not a proper list of terms.

                * Options is not a proper list of terms.

              Note  that not all individual Options are checked when the spawn
              request is sent. Some Options can only be checked  on  reception
              of  the  request.  Therefore  an invalid option does not cause a
              badarg exception, but will cause the  spawn  operation  to  fail
              with an error reason of badopt.

              A  spawn request can be abandoned by calling spawn_request_aban-
              don/1.

       spawn_request_abandon(ReqId :: reference()) -> boolean()

              Abandon a previously issued spawn request. ReqId corresponds  to
              a request identifier previously returned by spawn_request() in a
              call from current process. That is, only the  process  that  has
              made the request can abandon the request.

              A  spawn  request  can  only be successfully abandoned until the
              spawn request has completed. When a spawn request has been  suc-
              cessfully  abandoned,  the caller will not be effected by future
              direct effects of the spawn request itself. For example, it will
              not  receive  a  spawn reply message. The request is however not
              withdrawn, so a new process may or may not be created due to the
              request. If a new process is created after the spawn request was
              abandoned, no monitors nor links will be set up to the caller of
              spawn_request_abandon/1  due  to the spawn request. If the spawn
              request included the link option, the  process  created  due  to
              this  request  will  be sent an exit signal from its parent with
              the exit reason abandoned when it is detected that the spawn op-
              eration has succeeded.

          Note:
              A process created due to a spawn request that has been abandoned
              may communicate with its parent as any other process. It is only
              the  direct  effects  on the parent of the actual spawn request,
              that will be canceled by abandoning a spawn request.

              Return values:

                true:
                  The spawn request was successfully abandoned.

                false:
                  No spawn request was abandoned. The ReqId request identifier
                  did not correspond to an outstanding spawn request issued by
                  the calling process. The reason for this is either:

                  * ReqId corresponds to a spawn request  previoulsy  made  by
                    the calling process. The spawn operation has completed and
                    a spawn reply has already been delivered  to  the  calling
                    process  unless  the  spawn  reply was disabled in the re-
                    quest.

                  * ReqId does not correspond to a spawn request that has been
                    made by the calling process.

              This  function  fail  with  a badarg exception if ReqId is not a
              reference.

       split_binary(Bin, Pos) -> {binary(), binary()}

              Types:

                 Bin = binary()
                 Pos = integer() >= 0
                   0..byte_size(Bin)

              Returns a tuple containing the binaries that are the  result  of
              splitting  Bin into two parts at position Pos. This is not a de-
              structive operation. After the operation, there are three  bina-
              ries altogether. Example:

              > B = list_to_binary("0123456789").
              <<"0123456789">>
              > byte_size(B).
              10
              > {B1, B2} = split_binary(B,3).
              {<<"012">>,<<"3456789">>}
              > byte_size(B1).
              3
              > byte_size(B2).
              7

       erlang:start_timer(Time, Dest, Msg) -> TimerRef

              Types:

                 Time = integer() >= 0
                 Dest = pid() | atom()
                 Msg = term()
                 TimerRef = reference()

              Starts  a  timer.  The  same as calling erlang:start_timer(Time,
              Dest, Msg, []).

       erlang:start_timer(Time, Dest, Msg, Options) -> TimerRef

              Types:

                 Time = integer()
                 Dest = pid() | atom()
                 Msg = term()
                 Options = [Option]
                 Abs = boolean()
                 Option = {abs, Abs}
                 TimerRef = reference()

              Starts a timer. When the timer expires,  the  message  {timeout,
              TimerRef, Msg} is sent to the process identified by Dest.

              Options:

                {abs, false}:
                  This  is the default. It means the Time value is interpreted
                  as a time in milliseconds relative current Erlang  monotonic
                  time.

                {abs, true}:
                  Absolute Time value. The Time value is interpreted as an ab-
                  solute Erlang monotonic time in milliseconds.

              More Options can be added in the future.

              The absolute point in time, the timer is set to expire on,  must
              be  in the interval [erlang:system_info(start_time), erlang:sys-
              tem_info(end_time)]. If a relative time is specified,  the  Time
              value is not allowed to be negative.

              If  Dest  is a pid(), it must be a pid() of a process created on
              the current runtime system instance.  This  process  has  either
              terminated  or  not.  If Dest is an atom(), 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.

              If Dest is a pid(), the timer is automatically canceled  if  the
              process referred to by the pid() is not alive, or if the process
              exits. This feature was introduced in ERTS 5.4.11.  Notice  that
              timers are not automatically canceled when Dest is an atom().

              See  also  erlang:send_after/4,  erlang:cancel_timer/2,  and er-
              lang:read_timer/2.

              Failure: badarg if the arguments do not satisfy the requirements
              specified here.

       statistics(Item :: active_tasks) -> [ActiveTasks]

              Types:

                 ActiveTasks = integer() >= 0

              Returns the same as statistics(active_tasks_all) with the excep-
              tion that no information about the dirty IO run  queue  and  its
              associated schedulers is part of the result. That is, only tasks
              that are expected to be CPU bound are part of the result.

       statistics(Item :: active_tasks_all) -> [ActiveTasks]

              Types:

                 ActiveTasks = integer() >= 0

              Returns a list where each element represents the amount  of  ac-
              tive  processes  and  ports on each run queue and its associated
              schedulers. That is, the number of processes and ports that  are
              ready  to  run,  or are currently running. Values for normal run
              queues and their associated schedulers are located first in  the
              resulting  list. The first element corresponds to scheduler num-
              ber 1 and so on. If support for dirty schedulers exist, an  ele-
              ment  with the value for the dirty CPU run queue and its associ-
              ated dirty CPU schedulers follow and then as  last  element  the
              value for the the dirty IO run queue and its associated dirty IO
              schedulers follow. The information is not  gathered  atomically.
              That  is, the result is not necessarily a consistent snapshot of
              the state, but instead quite efficiently gathered.

          Note:
              Each normal scheduler has one run  queue  that  it  manages.  If
              dirty  schedulers schedulers are supported, all dirty CPU sched-
              ulers share one run queue, and all dirty IO schedulers share one
              run  queue.  That  is,  we  have multiple normal run queues, one
              dirty CPU run queue and one dirty IO run queue. Work can not mi-
              grate  between  the  different types of run queues. Only work in
              normal run queues can migrate to other normal run  queues.  This
              has to be taken into account when evaluating the result.

              See       also      statistics(total_active_tasks),      statis-
              tics(run_queue_lengths), statistics(run_queue_lengths_all), sta-
              tistics(total_run_queue_lengths),       and       statistics(to-
              tal_run_queue_lengths_all).

       statistics(Item :: context_switches) -> {ContextSwitches, 0}

              Types:

                 ContextSwitches = integer() >= 0

              Returns the total number of context switches  since  the  system
              started.

       statistics(Item :: exact_reductions) ->
                     {Total_Exact_Reductions,
                      Exact_Reductions_Since_Last_Call}

              Types:

                 Total_Exact_Reductions  =  Exact_Reductions_Since_Last_Call =
                 integer() >= 0

              Returns the number of exact reductions.

          Note:
              statistics(exact_reductions) is a more expensive operation  than
              statistics(reductions).

       statistics(Item :: garbage_collection) ->
                     {Number_of_GCs, Words_Reclaimed, 0}

              Types:

                 Number_of_GCs = Words_Reclaimed = integer() >= 0

              Returns information about garbage collection, for example:

              > statistics(garbage_collection).
              {85,23961,0}

              This information can be invalid for some implementations.

       statistics(Item :: io) -> {{input, Input}, {output, Output}}

              Types:

                 Input = Output = integer() >= 0

              Returns  Input,  which  is  the  total  number of bytes received
              through ports, and Output, which is the total  number  of  bytes
              output to ports.

       statistics(Item :: microstate_accounting) ->
                     [MSAcc_Thread] | undefined

              Types:

                 MSAcc_Thread =
                     #{type := MSAcc_Thread_Type,
                       id := MSAcc_Thread_Id,
                       counters := MSAcc_Counters}
                 MSAcc_Thread_Type =
                     async | aux | dirty_io_scheduler | dirty_cpu_scheduler |
                     poll | scheduler
                 MSAcc_Thread_Id = integer() >= 0
                 MSAcc_Counters = #{MSAcc_Thread_State => integer() >= 0}
                 MSAcc_Thread_State =
                     alloc | aux | bif | busy_wait | check_io | emulator | ets
                 |
                     gc | gc_fullsweep | nif | other | port | send |  sleep  |
                 timers

              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 some overhead exists when
              this is enabled. Microstate accounting is meant to be a  profil-
              ing   tool   to   help   finding   performance  bottlenecks.  To
              start/stop/reset microstate  accounting,  use  system  flag  mi-
              crostate_accounting.

              statistics(microstate_accounting)  returns a list of maps repre-
              senting some of the OS threads within ERTS.  Each  map  contains
              type  and  id 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.

              Example:

              > erlang:statistics(microstate_accounting).
              [#{counters => #{aux => 1899182914,
                               check_io => 2605863602,
                               emulator => 45731880463,
                               gc => 1512206910,
                               other => 5421338456,
                               port => 221631,
                               sleep => 5150294100},
                 id => 1,
                 type => scheduler}|...]

              The  time unit is the same as returned by os:perf_counter/0. So,
              to convert it to milliseconds, you can do something like this:

              lists:map(
                fun(#{ counters := Cnt } = M) ->
                        MsCnt = maps:map(fun(_K, PerfCount) ->
                                                 erlang:convert_time_unit(PerfCount, perf_counter, 1000)
                                         end, Cnt),
                       M#{ counters := MsCnt }
                end, erlang:statistics(microstate_accounting)).

              Notice that these values are not guaranteed to be the exact time
              spent  in  each  state.  This is because of various optimisation
              done to keep the overhead as small as possible.

              MSAcc_Thread_Types:

                scheduler:
                  The main execution threads that do most of the work. See erl
                  +S for more details.

                dirty_cpu_scheduler:
                  The  threads  for  long  running cpu intensive work. See erl
                  +SDcpu for more details.

                dirty_io_scheduler:
                  The threads for long running I/O work.  See  erl  +SDio  for
                  more details.

                async:
                  Async  threads are used by various linked-in drivers (mainly
                  the file drivers) do offload non-CPU intensive work. See erl
                  +A for more details.

                aux:
                  Takes  care of any work that is not specifically assigned to
                  a scheduler.

                poll:
                  Does the IO polling for the emulator. See erl +IOt for  more
                  details.

              The  following MSAcc_Thread_States 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.

                aux:
                  Time spent handling auxiliary jobs.

                check_io:
                  Time spent checking for new I/O events.

                emulator:
                  Time spent executing Erlang processes.

                gc:
                  Time spent doing garbage collection. When extra  states  are
                  enabled  this  is the time spent doing non-fullsweep garbage
                  collections.

                other:
                  Time spent doing unaccounted things.

                port:
                  Time spent executing ports.

                sleep:
                  Time spent sleeping.

              More fine-grained MSAcc_Thread_States can be added through  con-
              figure (such as ./configure --with-microstate-accounting=extra).
              Enabling these states causes performance  degradation  when  mi-
              crostate  accounting  is  turned  off and increases the overhead
              when it is turned on.

                alloc:
                  Time spent managing memory. Without extra states  this  time
                  is spread out over all other states.

                bif:
                  Time  spent  in BIFs. Without extra states this time is part
                  of the emulator state.

                busy_wait:
                  Time spent busy waiting. This is  also  the  state  where  a
                  scheduler  no  longer  reports  that it is active when using
                  statistics(scheduler_wall_time). 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 other state.

                ets:
                  Time spent executing ETS BIFs.  Without  extra  states  this
                  time is part of the emulator state.

                gc_full:
                  Time spent doing fullsweep garbage collection. Without extra
                  states this time is part of the gc state.

                nif:
                  Time spent in NIFs. Without extra states this time  is  part
                  of the emulator state.

                send:
                  Time  spent sending messages (processes only). Without extra
                  states this time is part of the emulator state.

                timers:
                  Time spent managing timers. Without extra states  this  time
                  is part of the other state.

              The  utility  module msacc(3erl) can be used to more easily ana-
              lyse these statistics.

              Returns undefined if system flag microstate_accounting is turned
              off.

              The  list  of  thread  information is unsorted and can appear in
              different order between calls.

          Note:
              The threads and states are subject to change without  any  prior
              notice.

       statistics(Item :: reductions) ->
                     {Total_Reductions, Reductions_Since_Last_Call}

              Types:

                 Total_Reductions  = Reductions_Since_Last_Call = integer() >=
                 0

              Returns information about reductions, for example:

              > statistics(reductions).
              {2046,11}

          Note:
              As from ERTS 5.5 (Erlang/OTP R11B), this value does not  include
              reductions  performed in current time slices of currently sched-
              uled processes. If an exact value is wanted, use  statistics(ex-
              act_reductions).

       statistics(Item :: run_queue) -> integer() >= 0

              Returns  the total length of all normal run-queues. That is, the
              number of processes and ports that  are  ready  to  run  on  all
              available  normal  run-queues.  Dirty run queues are not part of
              the result. 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    statistics(to-
              tal_run_queue_lengths), especially when a large amount of sched-
              ulers is used.

       statistics(Item :: run_queue_lengths) -> [RunQueueLength]

              Types:

                 RunQueueLength = integer() >= 0

              Returns the same as statistics(run_queue_lengths_all)  with  the
              exception  that  no  information about the dirty IO run queue is
              part of the result. That is, only run queues with work  that  is
              expected to be CPU bound is part of the result.

       statistics(Item :: run_queue_lengths_all) -> [RunQueueLength]

              Types:

                 RunQueueLength = integer() >= 0

              Returns  a list where each element represents the amount of pro-
              cesses and ports ready to run for each  run  queue.  Values  for
              normal  run  queues are located first in the resulting list. The
              first element corresponds to the normal run queue  of  scheduler
              number  1 and so on. If support for dirty schedulers exist, val-
              ues for the dirty CPU run queue and the dirty IO run queue  fol-
              low  (in that order) at the end. The information is not gathered
              atomically. That is, the result is not necessarily a  consistent
              snapshot of the state, but instead quite efficiently gathered.

          Note:
              Each  normal  scheduler  has  one  run queue that it manages. If
              dirty schedulers schedulers are supported, all dirty CPU  sched-
              ulers share one run queue, and all dirty IO schedulers share one
              run queue. That is, we have  multiple  normal  run  queues,  one
              dirty CPU run queue and one dirty IO run queue. Work can not mi-
              grate between the different types of run queues.  Only  work  in
              normal  run  queues can migrate to other normal run queues. This
              has to be taken into account when evaluating the result.

              See    also    statistics(run_queue_lengths),     statistics(to-
              tal_run_queue_lengths_all), statistics(total_run_queue_lengths),
              statistics(active_tasks), statistics(active_tasks_all), and sta-
              tistics(total_active_tasks), statistics(total_active_tasks_all).

       statistics(Item :: runtime) ->
                     {Total_Run_Time, Time_Since_Last_Call}

              Types:

                 Total_Run_Time = Time_Since_Last_Call = integer() >= 0

              Returns information about runtime, in milliseconds.

              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.

          Warning:
              This value might wrap due to limitations in the underlying func-
              tionality provided by the operating system that is used.

              Example:

              > statistics(runtime).
              {1690,1620}

       statistics(Item :: scheduler_wall_time) ->
                     [{SchedulerId, ActiveTime, TotalTime}] | undefined

              Types:

                 SchedulerId = integer() >= 1
                 ActiveTime = TotalTime = integer() >= 0

              Returns a list of tuples with {SchedulerId,  ActiveTime,  Total-
              Time},  where SchedulerId is an integer ID of the scheduler, Ac-
              tiveTime is the duration the scheduler has been busy, and Total-
              Time  is the total time duration since scheduler_wall_time acti-
              vation for the specific scheduler. Note that activation time can
              differ  significantly between schedulers. Currently dirty sched-
              ulers are activated at system start while normal schedulers  are
              activated  some time after the scheduler_wall_time functionality
              is enabled. The time unit is undefined and  can  be  subject  to
              change  between  releases,  OSs,  and  system  restarts.  sched-
              uler_wall_time is only to be used to calculate  relative  values
              for  scheduler  utilization.  ActiveTime can never exceed Total-
              Time.

              The definition of a busy scheduler is when it is not idle and is
              not scheduling (selecting) a process or port, that is:

                * Executing process code

                * Executing linked-in driver or NIF code

                * Executing BIFs, or any other runtime handling

                * Garbage collecting

                * Handling any other memory management

              Notice  that  a  scheduler  can  also be busy even if the OS has
              scheduled out the scheduler thread.

              Returns undefined if system flag scheduler_wall_time  is  turned
              off.

              The  list of scheduler information is unsorted and can appear in
              different order between calls.

              As of ERTS version 9.0, also dirty CPU schedulers  will  be  in-
              cluded  in  the  result. That is, all scheduler threads that are
              expected to handle CPU bound work. If you also want  information
              about    dirty    I/O    schedulers,    use    statistics(sched-
              uler_wall_time_all) instead.

              Normal schedulers will have scheduler identifiers in the range 1
              =<  SchedulerId  =<  erlang:system_info(schedulers).  Dirty  CPU
              schedulers will have scheduler  identifiers  in  the  range  er-
              lang:system_info(schedulers)   <   SchedulerId   =<  erlang:sys-
              tem_info(schedulers) + erlang:system_info(dirty_cpu_schedulers).

          Note:
              The different types of schedulers handle specific types of jobs.
              Every job is assigned to a specific scheduler type. Jobs can mi-
              grate between different schedulers of the same type,  but  never
              between schedulers of different types. This fact has to be taken
              under consideration when evaluating the result returned.

              Using scheduler_wall_time to calculate scheduler utilization:

              > erlang:system_flag(scheduler_wall_time, true).
              false
              > Ts0 = lists:sort(erlang:statistics(scheduler_wall_time)), ok.
              ok

              Some time later the user takes another snapshot  and  calculates
              scheduler utilization per scheduler, for example:

              > Ts1 = lists:sort(erlang:statistics(scheduler_wall_time)), ok.
              ok
              > lists:map(fun({{I, A0, T0}, {I, A1, T1}}) -> {I, (A1 - A0)/(T1 - T0)} end, lists:zip(Ts0,Ts1)).
              [{1,0.9743474730177548},
               {2,0.9744843782751444},
               {3,0.9995902361669045},
               {4,0.9738012596572161},
               {5,0.9717956667018103},
               {6,0.9739235846420741},
               {7,0.973237033077876},
               {8,0.9741297293248656}]

              Using the same snapshots to calculate a total scheduler utiliza-
              tion:

              > {A, T} = lists:foldl(fun({{_, A0, T0}, {_, A1, T1}}, {Ai,Ti}) -> {Ai + (A1 - A0), Ti + (T1 - T0)} end, {0, 0}, lists:zip(Ts0,Ts1)), TotalSchedulerUtilization = A/T.
              0.9769136803764825

              Total scheduler utilization will equal 1.0 when  all  schedulers
              have been active all the time between the two measurements.

              Another  (probably  more)  useful  value  is  to calculate total
              scheduler utilization weighted against maximum amount of  avail-
              able CPU time:

              > WeightedSchedulerUtilization = (TotalSchedulerUtilization * (erlang:system_info(schedulers) + erlang:system_info(dirty_cpu_schedulers))) / erlang:system_info(logical_processors_available).
              0.9769136803764825

              This  weighted  scheduler utilization will reach 1.0 when sched-
              ulers are active the same amount of time  as  maximum  available
              CPU  time.  If more schedulers exist than available logical pro-
              cessors, this value may be greater than 1.0.

              As of ERTS version 9.0, the Erlang runtime system  will  as  de-
              fault  have more schedulers than logical processors. This due to
              the dirty schedulers.

          Note:
              scheduler_wall_time is by default disabled. To  enable  it,  use
              erlang:system_flag(scheduler_wall_time, true).

       statistics(Item :: scheduler_wall_time_all) ->
                     [{SchedulerId, ActiveTime, TotalTime}] | undefined

              Types:

                 SchedulerId = integer() >= 1
                 ActiveTime = TotalTime = integer() >= 0

              The same as statistics(scheduler_wall_time), except that it also
              include information about all dirty I/O schedulers.

              Dirty IO schedulers will have scheduler identifiers in the range
              erlang:system_info(schedulers)           +           erlang:sys-
              tem_info(dirty_cpu_schedulers)  <  SchedulerId  =<   erlang:sys-
              tem_info(schedulers)  + erlang:system_info(dirty_cpu_schedulers)
              + erlang:system_info(dirty_io_schedulers).

          Note:
              Note that work executing on dirty I/O schedulers are expected to
              mainly  wait  for I/O. That is, when you get high scheduler uti-
              lization on dirty I/O schedulers, CPU  utilization  is  not  ex-
              pected to be high due to this work.

       statistics(Item :: total_active_tasks) -> ActiveTasks

              Types:

                 ActiveTasks = integer() >= 0

              The  same  as  calling  lists:sum(statistics(active_tasks)), but
              more efficient.

       statistics(Item :: total_active_tasks_all) -> ActiveTasks

              Types:

                 ActiveTasks = integer() >= 0

              The same as calling lists:sum(statistics(active_tasks_all)), but
              more efficient.

       statistics(Item :: total_run_queue_lengths) ->
                     TotalRunQueueLengths

              Types:

                 TotalRunQueueLengths = integer() >= 0

              The  same  as  calling lists:sum(statistics(run_queue_lengths)),
              but more efficient.

       statistics(Item :: total_run_queue_lengths_all) ->
                     TotalRunQueueLengths

              Types:

                 TotalRunQueueLengths = integer() >= 0

              The       same        as        calling        lists:sum(statis-
              tics(run_queue_lengths_all)), but more efficient.

       statistics(Item :: wall_clock) ->
                     {Total_Wallclock_Time,
                      Wallclock_Time_Since_Last_Call}

              Types:

                 Total_Wallclock_Time = Wallclock_Time_Since_Last_Call = inte-
                 ger() >= 0

              Returns information about wall clock. wall_clock can be used  in
              the same manner as runtime, except that real time is measured as
              opposed to runtime or CPU time.

       erlang:suspend_process(Suspendee) -> true

              Types:

                 Suspendee = pid()

              Suspends the process identified by Suspendee. The same as  call-
              ing erlang:suspend_process(Suspendee, []).

          Warning:
              This BIF is intended for debugging only.

       erlang:suspend_process(Suspendee, OptList) -> boolean()

              Types:

                 Suspendee = pid()
                 OptList = [Opt]
                 Opt  =  unless_suspending  |  asynchronous  |  {asynchronous,
                 term()}

              Increases the suspend count on the process  identified  by  Sus-
              pendee  and  puts it in the suspended state if it is not already
              in that state. A suspended process is not scheduled  for  execu-
              tion until the process has been resumed.

              A process can be suspended by multiple processes and can be sus-
              pended 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 Suspendee is  decreased  when
              erlang:resume_process(Suspendee)  is  called by the same process
              that  called  erlang:suspend_process(Suspendee).  All  increased
              suspend  counts on other processes acquired by a process are au-
              tomatically decreased when the process terminates.

              Options (Opts):

                asynchronous:
                  A suspend request is sent to the process identified by  Sus-
                  pendee.  Suspendee  eventually suspends unless it is resumed
                  before  it  could  suspend.  The   caller   of   erlang:sus-
                  pend_process/2  returns  immediately,  regardless of whether
                  Suspendee has suspended yet or not. The point in  time  when
                  Suspendee  suspends  cannot  be deduced from other events in
                  the system. It is only guaranteed that Suspendee  eventually
                  suspends  (unless it is resumed). If no asynchronous options
                  has been passed, the caller of  erlang:suspend_process/2  is
                  blocked until Suspendee has suspended.

                {asynchronous, ReplyTag}:
                  A  suspend request is sent to the process identified by Sus-
                  pendee. When the suspend request has been processed, a reply
                  message is sent to the caller of this function. The reply is
                  on the form {ReplyTag, State} where State is either:

                  exited:
                    Suspendee has exited.

                  suspended:
                    Suspendee is now suspended.

                  not_suspended:
                    Suspendee is not suspended. This can only happen when  the
                    process   that   issued  this  request,  have  called  re-
                    sume_process(Suspendee) before getting the reply.

                  Appart from the reply message, the {asynchronous,  ReplyTag}
                  option  behaves  exactly the same as the asynchronous option
                  without reply tag.

                unless_suspending:
                  The process identified by Suspendee is suspended unless  the
                  calling  process  already  is  suspending  Suspendee. If un-
                  less_suspending is combined with option asynchronous, a sus-
                  pend  request  is sent unless the calling process already is
                  suspending Suspendee or if a  suspend  request  already  has
                  been  sent and is in transit. If the calling process already
                  is suspending Suspendee, or if combined  with  option  asyn-
                  chronous  and a send request already is in transit, false is
                  returned and the suspend  count  on  Suspendee  remains  un-
                  changed.

              If  the  suspend count on the process identified by Suspendee is
              increased, true is returned, otherwise false.

          Warning:
              This BIF is intended for debugging only.

          Warning:
              You can easily create deadlocks if processes suspends each other
              (directly or in circles). In ERTS versions prior to ERTS version
              10.0, the runtime system prevented such deadlocks, but this pre-
              vention has now been removed due to performance reasons.

              Failures:

                badarg:
                   If Suspendee is not a process identifier.

                badarg:
                   If  the process identified by Suspendee is the same process
                  as the process calling erlang:suspend_process/2.

                badarg:
                   If the process identified by Suspendee is not alive.

                badarg:
                   If the process identified by Suspendee resides  on  another
                  node.

                badarg:
                   If OptList is not a proper list of valid Opts.

                system_limit:
                   If  the  process identified by Suspendee 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.

       erlang:system_flag(Flag :: backtrace_depth, Depth) -> OldDepth

              Types:

                 Depth = OldDepth = integer() >= 0

              Sets the maximum depth of call stack  back-traces  in  the  exit
              reason element of 'EXIT' tuples. The flag also limits the stack-
              trace depth returned by process_info item current_stacktrace.

              Returns the old value of the flag.

       erlang:system_flag(Flag :: cpu_topology, CpuTopology) ->
                             OldCpuTopology

              Types:

                 CpuTopology = OldCpuTopology = cpu_topology()
                 cpu_topology() = [LevelEntry :: level_entry()] | undefined
                 level_entry() =
                     {LevelTag :: level_tag(), SubLevel :: sub_level()} |
                     {LevelTag :: level_tag(),
                      InfoList :: info_list(),
                      SubLevel :: sub_level()}
                 level_tag() = core | node | processor | thread
                 sub_level() =
                     [LevelEntry :: level_entry()] |
                     (LogicalCpuId :: {logical, integer() >= 0})
                 info_list() = []

          Warning:
              This argument is deprecated. Instead of using this argument, use
              command-line argument +sct in erl(1).

              When  this  argument  is removed, a final CPU topology to use is
              determined at emulator boot time.

              Sets the user-defined CpuTopology. The user-defined CPU topology
              overrides  any  automatically  detected CPU topology. By passing
              undefined as CpuTopology, the system reverts to the CPU topology
              automatically  detected. The returned value equals the value re-
              turned from erlang:system_info(cpu_topology) before  the  change
              was made.

              Returns the old value of the flag.

              The CPU topology is used when binding schedulers to logical pro-
              cessors. If schedulers are already bound when the  CPU  topology
              is  changed, the schedulers are sent a request to rebind accord-
              ing to the new CPU topology.

              The user-defined CPU topology can also be set  by  passing  com-
              mand-line argument +sct to erl(1).

              For  information  on  type CpuTopology and more, see erlang:sys-
              tem_info(cpu_topology) as well as command-line  flags  +sct  and
              +sbt in erl(1).

       erlang:system_flag(Flag :: dirty_cpu_schedulers_online,
                          DirtyCPUSchedulersOnline) ->
                             OldDirtyCPUSchedulersOnline

              Types:

                 DirtyCPUSchedulersOnline  = OldDirtyCPUSchedulersOnline = in-
                 teger() >= 1

              Sets the number of dirty CPU schedulers online. Range  is  1  <=
              DirtyCPUSchedulersOnline  <=  N,  where N is the smallest of the
              return values  of  erlang:system_info(dirty_cpu_schedulers)  and
              erlang:system_info(schedulers_online).

              Returns the old value of the flag.

              The number of dirty CPU schedulers online can change if the num-
              ber of schedulers online changes. For example, if 12  schedulers
              and 6 dirty CPU schedulers are online, and system_flag/2 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  sched-
              ulers online increases proportionally to increases in the number
              of schedulers online.

              For more  information,  see  erlang:system_info(dirty_cpu_sched-
              ulers) and erlang:system_info(dirty_cpu_schedulers_online).

       erlang:system_flag(Flag :: erts_alloc, Value :: {Alloc, F, V}) ->
                             ok | notsup

              Types:

                 Alloc = F = atom()
                 V = integer()

              Sets  system  flags for erts_alloc(3erl). Alloc is the allocator
              to affect, for example binary_alloc. F is the flag to change and
              V is the new value.

              Only  a  subset  of  all  erts_alloc flags can be changed at run
              time. This subset is currently only the flag sbct.

              Returns ok if the flag was set or notsup  if  not  supported  by
              erts_alloc.

       erlang:system_flag(Flag :: fullsweep_after, Number) -> OldNumber

              Types:

                 Number = OldNumber = integer() >= 0

              Sets system flag fullsweep_after. Number is a non-negative inte-
              ger indicating how many times generational  garbage  collections
              can  be  done  without forcing a fullsweep collection. The value
              applies to new processes, while processes  already  running  are
              not affected.

              Returns the old value of the flag.

              In  low-memory systems (especially without virtual memory), set-
              ting the value to 0 can help to conserve memory.

              This value can also be set  through  (OS)  environment  variable
              ERL_FULLSWEEP_AFTER.

       erlang:system_flag(Flag :: microstate_accounting, Action) ->
                             OldState

              Types:

                 Action = true | false | reset
                 OldState = true | false

              Turns  on/off  microstate  accounting measurements. When passing
              reset, all counters are reset to 0.

              For more information see statistics(microstate_accounting).

       erlang:system_flag(Flag :: min_heap_size, MinHeapSize) ->
                             OldMinHeapSize

              Types:

                 MinHeapSize = OldMinHeapSize = integer() >= 0

              Sets the default minimum heap size for processes.  The  size  is
              specified in words. The new min_heap_size effects only processes
              spawned  after  the  change  of  min_heap_size  has  been  made.
              min_heap_size  can  be  set  for  individual  processes by using
              spawn_opt/4 or process_flag/2.

              Returns the old value of the flag.

       erlang:system_flag(Flag :: min_bin_vheap_size, MinBinVHeapSize) ->
                             OldMinBinVHeapSize

              Types:

                 MinBinVHeapSize = OldMinBinVHeapSize = integer() >= 0

              Sets the default minimum binary virtual heap size for processes.
              The  size is specified in words. The new min_bin_vhheap_size ef-
              fects   only   processes   spawned   after   the    change    of
              min_bin_vheap_size  has been made. min_bin_vheap_size can be set
              for   individual   processes   by   using   spawn_opt/2,3,4   or
              process_flag/2.

              Returns the old value of the flag.

       erlang:system_flag(Flag :: max_heap_size, MaxHeapSize) ->
                             OldMaxHeapSize

              Types:

                 MaxHeapSize = OldMaxHeapSize = max_heap_size()
                 max_heap_size() =
                     integer() >= 0 |
                     #{size => integer() >= 0,
                       kill => boolean(),
                       error_logger => boolean()}

              Sets  the  default maximum heap size settings for processes. The
              size is specified in words. The new max_heap_size  effects  only
              processes  spawned efter the change has been made. max_heap_size
              can be set for individual  processes  using  spawn_opt/2,3,4  or
              process_flag/2.

              Returns the old value of the flag.

       erlang:system_flag(Flag :: multi_scheduling, BlockState) ->
                             OldBlockState

              Types:

                 BlockState = block | unblock | block_normal | unblock_normal
                 OldBlockState = blocked | disabled | enabled

              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
              normal schedulers but one is blocked. When  only  normal  sched-
              ulers  are  blocked,  dirty  schedulers  are free to continue to
              schedule processes.

              If BlockState =:= block, multi-scheduling is blocked.  That  is,
              one  and  only  one scheduler thread will execute. If BlockState
              =:= unblock and no one else blocks  multi-scheduling,  and  this
              process has blocked only once, multi-scheduling is unblocked.

              If  BlockState  =:=  block_normal,  normal  multi-scheduling  is
              blocked. That is, only one normal scheduler thread will execute,
              but multiple dirty schedulers can execute. If BlockState =:= un-
              block_normal and no one else blocks normal multi-scheduling, and
              this  process  has blocked only once, normal multi-scheduling is
              unblocked.

              One process can block multi-scheduling and normal multi-schedul-
              ing  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 nor-
              mal multi-scheduling.

              The return values are disabled, blocked, blocked_normal, or  en-
              abled.  The  returned  value  describes the state just after the
              call  to  erlang:system_flag(multi_scheduling,  BlockState)  has
              been  made.  For  information  about  the return values, see er-
              lang:system_info(multi_scheduling).

          Note:
              Blocking of multi-scheduling and normal multi-scheduling is nor-
              mally  not  needed.  If you feel that you need to use these fea-
              tures, consider it a few more times again. Blocking multi-sched-
              uling  is only to be used as a last resort, as it is most likely
              a very inefficient way to solve the problem.

              See   also   erlang:system_info(multi_scheduling),   erlang:sys-
              tem_info(normal_multi_scheduling_blockers),          erlang:sys-
              tem_info(multi_scheduling_blockers),       and       erlang:sys-
              tem_info(schedulers).

       erlang:system_flag(Flag :: scheduler_bind_type, How) ->
                             OldBindType

              Types:

                 How = scheduler_bind_type() | default_bind
                 OldBindType = scheduler_bind_type()
                 scheduler_bind_type() =
                     no_node_processor_spread | no_node_thread_spread | no_spread |
                     processor_spread | spread | thread_spread |
                     thread_no_node_processor_spread | unbound

          Warning:
              This argument is deprecated. Instead of using this argument, use
              command-line argument +sbt in erl(1). When this argument is  re-
              moved,  a final scheduler bind type to use is determined at emu-
              lator boot time.

              Controls if and how schedulers are bound to logical processors.

              When erlang:system_flag(scheduler_bind_type, How) is called,  an
              asynchronous  signal  is  sent to all schedulers online, causing
              them to try to bind or unbind as requested.

          Note:
              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, an error event is  logged.
              To  verify that the schedulers have bound as requested, call er-
              lang:system_info(scheduler_bindings).

              Schedulers can be bound on newer Linux,  Solaris,  FreeBSD,  and
              Windows  systems,  but  more systems will be supported in future
              releases.

              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 +sct in erl(1).

              The runtime system does by default not bind schedulers to  logi-
              cal processors.

          Note:
              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 pro-
              cessors,  there  can be a performance penalty instead. Sometimes
              this performance penalty can be severe. If so, it is recommended
              to not bind the schedulers.

              Schedulers  can  be bound in different ways. Argument How deter-
              mines how schedulers are bound and can be any of the following:

                unbound:
                  Same as command-line argument +sbt u in erl(1).

                no_spread:
                  Same as command-line argument +sbt ns in erl(1).

                thread_spread:
                  Same as command-line argument +sbt ts in erl(1).

                processor_spread:
                  Same as command-line argument +sbt ps in erl(1).

                spread:
                  Same as command-line argument +sbt s in erl(1).

                no_node_thread_spread:
                  Same as command-line argument +sbt nnts in erl(1).

                no_node_processor_spread:
                  Same as command-line argument +sbt nnps in erl(1).

                thread_no_node_processor_spread:
                  Same as command-line argument +sbt tnnps in erl(1).

                default_bind:
                  Same as command-line argument +sbt db in erl(1).

              The returned value equals How  before  flag  scheduler_bind_type
              was changed.

              Failures:

                notsup:
                  If binding of schedulers is not supported.

                badarg:
                  If How is not one of the documented alternatives.

                badarg:
                  If CPU topology information is unavailable.

              The  scheduler bind type can also be set by passing command-line
              argument +sbt to erl(1).

              For    more    information,    see     erlang:system_info(sched-
              uler_bind_type), erlang:system_info(scheduler_bindings), as well
              as command-line flags +sbt and +sct in erl(1).

       erlang:system_flag(Flag :: scheduler_wall_time, Boolean) ->
                             OldBoolean

              Types:

                 Boolean = OldBoolean = boolean()

              Turns on or off scheduler wall time measurements.

              For more information, see statistics(scheduler_wall_time).

       erlang:system_flag(Flag :: schedulers_online, SchedulersOnline) ->
                             OldSchedulersOnline

              Types:

                 SchedulersOnline = OldSchedulersOnline = integer() >= 1

              Sets the number of schedulers online. Range is 1  <=  Scheduler-
              sOnline <= erlang:system_info(schedulers).

              Returns the old value of the flag.

              If  the  emulator  was built with support for  dirty schedulers,
              changing the number of schedulers online  can  also  change  the
              number of dirty CPU schedulers online. For example, if 12 sched-
              ulers and 6 dirty CPU schedulers are online,  and  system_flag/2
              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.

              For more information, see erlang:system_info(schedulers) and er-
              lang:system_info(schedulers_online).

       erlang:system_flag(Flag :: system_logger, Logger) -> PrevLogger

              Types:

                 Logger = PrevLogger = logger | undefined | pid()

              Sets the process that will receive the logging  messages  gener-
              ated  by  ERTS. If set to undefined, all logging messages gener-
              ated by ERTS will be dropped. The messages will be in  the  for-
              mat:

              {log,Level,Format,ArgList,Metadata} where

              Level = atom(),
              Format = string(),
              ArgList = list(term()),
              Metadata = #{ pid => pid(),
                 group_leader => pid(),
                 time := logger:timestamp(),
                 error_logger := #{ emulator := true, tag := atom() }

              If  the  system_logger  process dies, this flag will be reset to
              logger.

              The default is the process named logger.

              Returns the old value of the flag.

          Note:
              This function is designed to be used by the  KERNEL  logger.  Be
              careful  if  you change it to something else as log messages may
              be lost. If you want to intercept emulator log messages,  do  it
              by adding a specialized handler to the KERNEL logger.

       erlang:system_flag(Flag :: trace_control_word, TCW) -> OldTCW

              Types:

                 TCW = OldTCW = integer() >= 0

              Sets  the  value of the node trace control word to TCW, which is
              to be an unsigned integer. For more  information,  see  function
              set_tcw  in  section  "Match  Specifications  in  Erlang" in the
              User's Guide.

              Returns the old value of the flag.

       erlang:system_flag(Flag :: time_offset, Value :: finalize) ->
                             OldState

              Types:

                 OldState = preliminary | final | volatile

              Finalizes the time offset when single time warp mode is used. If
              another  time  warp  mode is used, the time offset state is left
              unchanged.

              Returns the old state identifier, that is:

                * If preliminary is returned, finalization was  performed  and
                  the time offset is now final.

                * If final is returned, the time offset was already in the fi-
                  nal  state.  This   either   because   another   erlang:sys-
                  tem_flag(time_offset, finalize) call or because no time warp
                  mode is used.

                * If volatile is returned, the time offset cannot be finalized
                  because multi-time warp mode is used.

       erlang:system_info(Item :: overview) -> boolean()

              Returns  information about the current system. The documentation
              of this function is broken into the following sections in  order
              to make it easier to navigate.

                Memory Allocation:
                  allocated_areas,  allocator,  alloc_util_allocators, alloca-
                  tor_sizes, elib_malloc

                CPU Topology:
                  cpu_topology, logical_processors, update_cpu_info

                Process Information:
                  fullsweep_after, garbage_collection, heap_sizes,  heap_type,
                  max_heap_size,       message_queue_data,      min_heap_size,
                  min_bin_vheap_size, procs

                System Limits:
                  atom_count, atom_limit,  ets_count,  ets_limit,  port_count,
                  port_limit, process_count, process_limit

                System Time:
                  end_time,  os_monotonic_time_source,  os_system_time_source,
                  start_time,  time_correction,  time_offset,  time_warp_mode,
                  tolerant_timeofday

                Scheduler Information:
                  dirty_cpu_schedulers,           dirty_cpu_schedulers_online,
                  dirty_io_schedulers,    multi_scheduling,     multi_schedul-
                  ing_blockers,    normal_multi_scheduling_blockers,    sched-
                  uler_bind_type,  scheduler_bindings,  scheduler_id,   sched-
                  ulers, smp_support, threads, thread_pool_size

                Distribution Information:
                  creation,  delayed_node_table_gc, dist, dist_buf_busy_limit,
                  dist_ctrl

                System Information:
                  build_type,  c_compiler_used,  check_io,   compat_rel,   de-
                  bug_compiled,     driver_version,     dynamic_trace,     dy-
                  namic_trace_probes, info, kernel_poll, loaded, machine, mod-
                  ified_timing_level, nif_version, otp_release, port_parallel-
                  ism,  system_architecture,  system_logger,   system_version,
                  trace_control_word, version, wordsize

       erlang:system_info(Item :: allocated_areas) -> [tuple()]

       erlang:system_info(Item :: allocator) ->
                             {Allocator, Version, Features, Settings}

       erlang:system_info(Item :: {allocator, Alloc}) -> [term()]

       erlang:system_info(Item :: alloc_util_allocators) -> [Alloc]

       erlang:system_info(Item :: {allocator_sizes, Alloc}) -> [term()]

       erlang:system_info(Item :: elib_malloc) -> false

              Types:

                 Allocator = undefined | glibc
                 Version = [integer() >= 0]
                 Features = [atom()]
                 Settings =
                     [{Subsystem :: atom(),
                       [{Parameter :: atom(), Value :: term()}]}]
                 Alloc = atom()

              Returns  various  information about the memory allocators of the
              current system (emulator) as specified by Item:

                allocated_areas:
                  Returns a list of tuples with  information  about  miscella-
                  neous allocated memory areas.

                  Each tuple contains an atom describing the type of memory as
                  first element and the amount of allocated memory in bytes as
                  second  element.  When  information about allocated and used
                  memory is present, also a third element is present, contain-
                  ing the amount of used memory in bytes.

                  erlang:system_info(allocated_areas)  is  intended for debug-
                  ging, and the content  is  highly  implementation-dependent.
                  The  content  of  the  results therefore changes when needed
                  without prior notice.

                  Notice that the sum of these values is not 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  re-
                  sult. For information about the total amount of memory allo-
                  cated by the emulator, see erlang:memory/0,1.

                allocator:
                  Returns {Allocator, Version, Features, Settings, where:

                  * Allocator corresponds to the malloc() implementation used.
                    If Allocator equals undefined, the malloc() implementation
                    used cannot be identified. glibc can be identified.

                  * Version is a list of integers (but not  a  string)  repre-
                    senting the version of the malloc() implementation used.

                  * Features  is  a  list of atoms representing the allocation
                    features used.

                  * Settings is a list of subsystems, their  configurable  pa-
                    rameters,  and  used  values.  Settings can differ between
                    different combinations of platforms, allocators, and allo-
                    cation features. Memory sizes are given in bytes.

                  See  also  "System  Flags  Effecting erts_alloc" in erts_al-
                  loc(3erl).

                {allocator, Alloc}:
                  Returns information about the specified allocator.  As  from
                  ERTS 5.6.1, the return value is a list of {instance, Instan-
                  ceNo, InstanceInfo} tuples, where InstanceInfo contains  in-
                  formation about a specific instance of the allocator. If Al-
                  loc is not a recognized allocator, undefined is returned. If
                  Alloc is disabled, false is returned.

                  Notice  that  the information returned is highly implementa-
                  tion-dependent and can be changed or  removed  at  any  time
                  without  prior  notice.  It was initially intended as a tool
                  when developing new allocators, but as it can be of interest
                  for others it has been briefly documented.

                  The  recognized  allocators  are listed in erts_alloc(3erl).
                  Information about super carriers can be obtained  from  ERTS
                  8.0 with {allocator, erts_mmap} or from ERTS 5.10.4; the re-
                  turned list when calling with {allocator,  mseg_alloc}  also
                  includes an {erts_mmap, _} tuple as one element in the list.

                  After  reading  the  erts_alloc(3erl) documentation, the re-
                  turned information more or less speaks for  itself,  but  it
                  can  be  worth  explaining some things. Call counts are pre-
                  sented by two values, the first value is giga calls, and the
                  second value is calls. mbcs and sbcs denote multi-block car-
                  riers, and single-block carriers,  respectively.  Sizes  are
                  presented  in bytes. When a size is not presented, it is the
                  amount of something. Sizes and amounts are  often  presented
                  by three values:

                  * The first is the current value.

                  * The second is the maximum value since the last call to er-
                    lang:system_info({allocator, Alloc}).

                  * The third is the maximum  value  since  the  emulator  was
                    started.

                  If  only  one  value  is  present,  it is the current value.
                  fix_alloc 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.

                alloc_util_allocators:
                  Returns a list of the names of all allocators using the ERTS
                  internal  alloc_util  framework  as atoms. For more informa-
                  tion, see  section  The  alloc_util  framework  in  erts_al-
                  loc(3erl).

                {allocator_sizes, Alloc}:
                  Returns  various  size information for the specified alloca-
                  tor. The information returned is a subset of the information
                  returned by erlang:system_info({allocator, Alloc}).

                elib_malloc:
                  This  option will be removed in a future release. The return
                  value will always be false, as the elib_malloc allocator has
                  been removed.

       erlang:system_info(Item :: cpu_topology) -> CpuTopology

       erlang:system_info(Item ::
                              {cpu_topology, defined | detected | used}) ->
                             CpuTopology

       erlang:system_info(Item ::
                              logical_processors |
                              logical_processors_available |
                              logical_processors_online) ->
                             unknown | integer() >= 1

       erlang:system_info(Item :: update_cpu_info) -> changed | unchanged

              Types:

                 cpu_topology() = [LevelEntry :: level_entry()] | undefined
                    All  LevelEntrys of a list must contain the same LevelTag,
                   except on the top level  where  both  node  and  processor-
                   LevelTags can coexist.
                 level_entry() =
                     {LevelTag :: level_tag(), SubLevel :: sub_level()} |
                     {LevelTag :: level_tag(),
                      InfoList :: info_list(),
                      SubLevel :: sub_level()}
                   {LevelTag, SubLevel} == {LevelTag, [], SubLevel}
                 level_tag() = core | node | processor | thread
                    More LevelTags can be introduced in a future release.
                 sub_level() =
                     [LevelEntry :: level_entry()] |
                     (LogicalCpuId :: {logical, integer() >= 0})
                 info_list() = []
                    The info_list() can be extended in a future release.

              Returns  various  information about the CPU topology of the cur-
              rent system (emulator) as specified by Item:

                cpu_topology:
                  Returns the CpuTopology currently used by the emulator.  The
                  CPU topology is used when binding schedulers to logical pro-
                  cessors. The CPU topology  used  is  the   user-defined  CPU
                  topology,  if  such exists, otherwise the  automatically de-
                  tected CPU topology, if such exists. If no CPU topology  ex-
                  ists, undefined is returned.

                  node  refers  to  Non-Uniform  Memory  Access  (NUMA) nodes.
                  thread refers to hardware threads (for example, Intel hyper-
                  threads).

                  A level in term CpuTopology can be omitted if only one entry
                  exists and InfoList is empty.

                  thread can only be a sublevel to core. core can  be  a  sub-
                  level  to  processor  or  node.  processor can be on the top
                  level or a sublevel to node. node can be on the top level or
                  a  sublevel to processor. That is, NUMA nodes can be proces-
                  sor internal or processor external. A CPU topology can  con-
                  sist of a mix of processor internal and external NUMA nodes,
                  as long as each logical CPU belongs to one NUMA node.  Cache
                  hierarchy  is  not part of the CpuTopology 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 CpuTopology
                  type to change.

                {cpu_topology, defined}:

                  Returns the user-defined CpuTopology. For more  information,
                  see command-line flag +sct in erl(1) and argument cpu_topol-
                  ogy.

                {cpu_topology, detected}:

                  Returns the automatically detected CpuTopologyy. The  emula-
                  tor  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 de-
                  tected.

                  For more information, see argument cpu_topology.

                {cpu_topology, used}:
                  Returns CpuTopology used by the emulator. For more  informa-
                  tion, see argument cpu_topology.

                logical_processors:
                  Returns the detected number of logical processors configured
                  in the system. The return value is either an integer, or the
                  atom  unknown  if  the emulator cannot detect the configured
                  logical processors.

                logical_processors_available:
                  Returns the detected number of logical processors  available
                  to  the Erlang runtime system. The return value is either an
                  integer, or the atom unknown if the emulator  cannot  detect
                  the  available  logical  processors. The number of available
                  logical processors is less than or equal to  the  number  of
                  logical processors online.

                logical_processors_online:
                  Returns  the detected number of logical processors online on
                  the system. The return value is either an  integer,  or  the
                  atom  unknown  if the emulator cannot detect logical proces-
                  sors online. The number of logical processors online is less
                  than  or  equal  to the number of logical processors config-
                  ured.

                cpu_quota:
                  Returns the detected CPU quota the emulator is  limited  by.
                  The  return  value is an integer saying how many processors'
                  worth of runtime we get (between 1 and the number of logical
                  processors),  or the atom unknown if the emulator cannot de-
                  tect a quota.

                update_cpu_info:
                  The runtime system rereads the CPU information available and
                  updates its internally stored information about the detected
                  CPU topology and the number of  logical  processors  config-
                  ured, online, available, and cpu quota.

                  If  the  CPU  information has changed since the last time it
                  was read, the atom changed is returned, otherwise  the  atom
                  unchanged.  If the CPU information has changed, you probably
                  want to adjust the number of schedulers  online.  You  typi-
                  cally want to have as many schedulers online as logical pro-
                  cessors available.

       erlang:system_info(Item :: fullsweep_after) ->
                             {fullsweep_after, integer() >= 0}

       erlang:system_info(Item :: garbage_collection) ->
                             [{atom(), integer()}]

       erlang:system_info(Item :: heap_sizes) -> [integer() >= 0]

       erlang:system_info(Item :: heap_type) -> private

       erlang:system_info(Item :: max_heap_size) ->
                             {max_heap_size,
                              MaxHeapSize :: max_heap_size()}

       erlang:system_info(Item :: message_queue_data) ->
                             message_queue_data()

       erlang:system_info(Item :: min_heap_size) ->
                             {min_heap_size,
                              MinHeapSize :: integer() >= 1}

       erlang:system_info(Item :: min_bin_vheap_size) ->
                             {min_bin_vheap_size,
                              MinBinVHeapSize :: integer() >= 1}

       erlang:system_info(Item :: procs) -> binary()

              Types:

                 message_queue_data() = off_heap | on_heap
                 max_heap_size() =
                     integer() >= 0 |
                     #{size => integer() >= 0,
                       kill => boolean(),
                       error_logger => boolean()}

              Returns information about the default process heap settings:

                fullsweep_after:
                  Returns {fullsweep_after, integer()  >=  0},  which  is  the
                  fullsweep_after  garbage collection setting used by default.
                  For more information, see garbage_collection  described  be-
                  low.

                garbage_collection:
                  Returns  a  list  describing  the default garbage collection
                  settings. A process spawned on the local node by a spawn  or
                  spawn_link  uses  these garbage collection settings. The de-
                  fault settings can be changed by using erlang:system_flag/2.
                  spawn_opt/2,3,4  can  spawn  a process that does not use the
                  default settings.

                heap_sizes:
                  Returns a list of integers representing valid heap sizes  in
                  words. All Erlang heaps are sized from sizes in this list.

                heap_type:
                  Returns the heap type used by the current emulator. One heap
                  type exists:

                  private:
                     Each process has a heap reserved for its use and no  ref-
                    erences  between heaps of different processes are allowed.
                    Messages  passed  between  processes  are  copied  between
                    heaps.

                max_heap_size:
                  Returns  {max_heap_size,  MaxHeapSize}, where MaxHeapSize is
                  the current  system-wide  maximum  heap  size  settings  for
                  spawned  processes.  This  setting can be set using the com-
                  mand-line flags +hmax, +hmaxk and +hmaxel in erl(1). It  can
                  also    be    changed    at    runtime   using   erlang:sys-
                  tem_flag(max_heap_size, MaxHeapSize). For more details about
                  the        max_heap_size       process       flag,       see
                  process_flag(max_heap_size, MaxHeapSize).

                message_queue_data:
                  Returns the default value of the message_queue_data  process
                  flag,  which  is either off_heap or on_heap. This default is
                  set by command-line argument +hmqd in erl(1). For  more  in-
                  formation  on the message_queue_data process flag, see docu-
                  mentation of process_flag(message_queue_data, MQD).

                min_heap_size:
                  Returns {min_heap_size, MinHeapSize}, where  MinHeapSize  is
                  the  current  system-wide minimum heap size for spawned pro-
                  cesses.

                min_bin_vheap_size:
                  Returns {min_bin_vheap_size, MinBinVHeapSize}, where MinBin-
                  VHeapSize  is the current system-wide minimum binary virtual
                  heap size for spawned processes.

                procs:
                  Returns a binary containing a string of process and port in-
                  formation  formatted  as in Erlang crash dumps. For more in-
                  formation, see section  How to interpret  the  Erlang  crash
                  dumps in the User's Guide.

       erlang:system_info(Item :: atom_count) -> integer() >= 1

       erlang:system_info(Item :: atom_limit) -> integer() >= 1

       erlang:system_info(Item :: ets_count) -> integer() >= 1

       erlang:system_info(Item :: ets_limit) -> integer() >= 1

       erlang:system_info(Item :: port_count) -> integer() >= 0

       erlang:system_info(Item :: port_limit) -> integer() >= 1

       erlang:system_info(Item :: process_count) -> integer() >= 1

       erlang:system_info(Item :: process_limit) -> integer() >= 1

              Returns  information  about the current system (emulator) limits
              as specified by Item:

                atom_count:
                  Returns the number of atoms currently existing at the  local
                  node. The value is given as an integer.

                atom_limit:
                  Returns  the maximum number of atoms allowed. This limit can
                  be increased at startup by passing command-line flag  +t  to
                  erl(1).

                ets_count:
                  Returns  the  number of ETS tables currently existing at the
                  local node.

                ets_limit:
                  Returns the limit for number of ETS tables.  This  limit  is
                  partially  obsolete and number of tables are only limited by
                  available memory.

                port_count:
                  Returns the number of ports currently existing at the  local
                  node.  The  value  is  given as an integer. This is the same
                  value as returned by length(erlang:ports()), but more  effi-
                  cient.

                port_limit:
                  Returns  the maximum number of simultaneously existing ports
                  at the local node as an integer. This limit can  be  config-
                  ured at startup by using command-line flag +Q in erl(1).

                process_count:
                  Returns  the  number  of processes currently existing at the
                  local node. The value is given as an integer.  This  is  the
                  same  value as returned by length(processes()), but more ef-
                  ficient.

                process_limit:
                  Returns the maximum number of simultaneously  existing  pro-
                  cesses  at the local node. The value is given as an integer.
                  This limit can be configured at startup  by  using  command-
                  line flag +P in erl(1).

       erlang:system_info(Item :: end_time) -> integer() >= 0

       erlang:system_info(Item :: os_monotonic_time_source) ->
                             [{atom(), term()}]

       erlang:system_info(Item :: os_system_time_source) ->
                             [{atom(), term()}]

       erlang:system_info(Item :: start_time) -> integer()

       erlang:system_info(Item :: time_correction) -> true | false

       erlang:system_info(Item :: time_offset) ->
                             preliminary | final | volatile

       erlang:system_info(Item :: time_warp_mode) ->
                             no_time_warp | single_time_warp |
                             multi_time_warp

       erlang:system_info(Item :: tolerant_timeofday) ->
                             enabled | disabled

              Returns  information about the current system (emulator) time as
              specified by Item:

                end_time:
                  The last Erlang monotonic time in native time unit that  can
                  be represented internally in the current Erlang runtime sys-
                  tem instance. The time between the start time  and  the  end
                  time is at least a quarter of a millennium.

                os_monotonic_time_source:
                  Returns a list containing information about the source of OS
                  monotonic time that is used by the runtime system.

                  If [] is returned, no OS monotonic time  is  available.  The
                  list  contains  two-tuples  with  Keys as first element, and
                  Values as second element. The order of these tuples is unde-
                  fined.  The  following  tuples  can be part of the list, but
                  more tuples can be introduced in the future:

                  {function, Function}:
                    Function is the name of the function used. This tuple  al-
                    ways  exists if OS monotonic time is available to the run-
                    time system.

                  {clock_id, ClockId}:
                    This tuple only exists if Function can be used  with  dif-
                    ferent clocks. ClockId corresponds to the clock identifier
                    used when calling Function.

                  {resolution, OsMonotonicTimeResolution}:
                    Highest possible  resolution of current OS monotonic  time
                    source  as  parts per second. If no resolution information
                    can be retrieved from the OS, OsMonotonicTimeResolution is
                    set to the resolution of the time unit of Functions return
                    value. That is, the actual resolution can  be  lower  than
                    OsMonotonicTimeResolution. Notice that the resolution does
                    not say anything about the  accuracy or whether the   pre-
                    cision  aligns  with the resolution. You do, however, know
                    that the precision is not better than OsMonotonicTimeReso-
                    lution.

                  {extended, Extended}:
                    Extended  equals  yes if the range of time values has been
                    extended; otherwise Extended equals no. The range must  be
                    extended  if  Function returns values that wrap fast. This
                    typically is the case when the return value  is  a  32-bit
                    value.

                  {parallel, Parallel}:
                    Parallel equals yes if Function is called in parallel from
                    multiple threads. If it is not called in parallel, because
                    calls must be serialized, Parallel equals no.

                  {time, OsMonotonicTime}:
                    OsMonotonicTime equals current OS monotonic time in native
                    time unit.

                os_system_time_source:
                  Returns a list containing information about the source of OS
                  system time that is used by the runtime system.

                  The list contains two-tuples with Keys as first element, and
                  Values as second element. The order of these tuples is unde-
                  fined.  The  following  tuples  can be part of the list, but
                  more tuples can be introduced in the future:

                  {function, Function}:
                    Function is the name of the funcion used.

                  {clock_id, ClockId}:
                    Exists only if Function can be used with different clocks.
                    ClockId  corresponds  to  the  clock  identifier used when
                    calling Function.

                  {resolution, OsSystemTimeResolution}:
                    Highest possible  resolution of  current  OS  system  time
                    source  as  parts per second. If no resolution information
                    can be retrieved from the  OS,  OsSystemTimeResolution  is
                    set to the resolution of the time unit of Functions return
                    value. That is, the actual resolution can  be  lower  than
                    OsSystemTimeResolution.  Notice  that  the resolution does
                    not say anything about the  accuracy or whether the   pre-
                    cision do align with the resolution. You do, however, know
                    that the precision is not better than  OsSystemTimeResolu-
                    tion.

                  {parallel, Parallel}:
                    Parallel equals yes if Function is called in parallel from
                    multiple threads. If it is not called in parallel, because
                    calls needs to be serialized, Parallel equals no.

                  {time, OsSystemTime}:
                    OsSystemTime  equals current OS system time in native time
                    unit.

                start_time:
                  The Erlang monotonic time in native time unit  at  the  time
                  when current Erlang runtime system instance started.

                  See also erlang:system_info(end_time).

                time_correction:
                  Returns  a boolean value indicating whether  time correction
                  is enabled or not.

                time_offset:
                  Returns the state of the time offset:

                  preliminary:
                    The time offset is preliminary, and will  be  changed  and
                    finalized  later. The preliminary time offset is used dur-
                    ing the preliminary phase of the  single time warp mode.

                  final:
                    The time offset is final. This  either  because   no  time
                    warp  mode  is  used, or because the time offset have been
                    finalized when  single time warp mode is used.

                  volatile:
                    The time offset is volatile. That is, it can change at any
                    time. This is because  multi-time warp mode is used.

                time_warp_mode:
                  Returns  a  value  identifying  the   time warp mode that is
                  used:

                  no_time_warp:
                    The  no time warp mode is used.

                  single_time_warp:
                    The  single time warp mode is used.

                  multi_time_warp:
                    The  multi-time warp mode is used.

                tolerant_timeofday:
                  Returns whether a pre ERTS 7.0 backwards compatible  compen-
                  sation  for sudden changes of system time is enabled or dis-
                  abled. Such compensation is enabled when the time offset  is
                  final, and  time correction is enabled.

       erlang:system_info(Item :: dirty_cpu_schedulers) ->
                             integer() >= 0

       erlang:system_info(Item :: dirty_cpu_schedulers_online) ->
                             integer() >= 0

       erlang:system_info(Item :: dirty_io_schedulers) ->
                             integer() >= 0

       erlang:system_info(Item :: multi_scheduling) ->
                             disabled | blocked | blocked_normal |
                             enabled

       erlang:system_info(Item :: multi_scheduling_blockers) ->
                             [Pid :: pid()]

       erlang:system_info(Item :: otp_release) -> string()

       erlang:system_info(Item :: scheduler_bind_type) ->
                             spread | processor_spread | thread_spread |
                             thread_no_node_processor_spread |
                             no_node_processor_spread |
                             no_node_thread_spread | no_spread | unbound

       erlang:system_info(Item :: scheduler_bindings) -> tuple()

       erlang:system_info(Item :: scheduler_id) ->
                             SchedulerId :: integer() >= 1

       erlang:system_info(Item :: schedulers | schedulers_online) ->
                             integer() >= 1

       erlang:system_info(Item :: smp_support) -> boolean()

       erlang:system_info(Item :: threads) -> boolean()

       erlang:system_info(Item :: thread_pool_size) -> integer() >= 0

              Returns  information about schedulers, scheduling and threads in
              the current system as specified by Item:

                dirty_cpu_schedulers:
                  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,  and  BIFs
                  that cannot be managed cleanly by the normal emulator sched-
                  ulers.

                  The number of dirty CPU scheduler threads is  determined  at
                  emulator  boot  time  and cannot be changed after that. How-
                  ever, the number of dirty CPU scheduler threads  online  can
                  be  changed  at any time. The number of dirty CPU schedulers
                  can be set at startup by passing command-line flag +SDcpu or
                  +SDPcpu in erl(1).

                  See   also   erlang:system_flag(dirty_cpu_schedulers_online,
                  DirtyCPUSchedulersOnline),                       erlang:sys-
                  tem_info(dirty_cpu_schedulers_online),           erlang:sys-
                  tem_info(dirty_io_schedulers),     erlang:system_info(sched-
                  ulers),   erlang:system_info(schedulers_online),   and   er-
                  lang:system_flag(schedulers_online, SchedulersOnline).

                dirty_cpu_schedulers_online:
                  Returns the number of dirty CPU schedulers online.  The  re-
                  turn  value  satisfies  1  <= DirtyCPUSchedulersOnline <= N,
                  where N is the smallest of the return values of  erlang:sys-
                  tem_info(dirty_cpu_schedulers) and erlang:system_info(sched-
                  ulers_online).

                  The number of dirty CPU schedulers  online  can  be  set  at
                  startup by passing command-line flag +SDcpu in erl(1).

                  For       more       information,       see      erlang:sys-
                  tem_info(dirty_cpu_schedulers),                  erlang:sys-
                  tem_info(dirty_io_schedulers),     erlang:system_info(sched-
                  ulers_online),    and    erlang:system_flag(dirty_cpu_sched-
                  ulers_online, DirtyCPUSchedulersOnline).

                dirty_io_schedulers:
                  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 man-
                  aged cleanly by the normal emulator schedulers.

                  This value can be set at startup by passing command-line ar-
                  gument +SDio in erl(1).

                  For       more       information,       see      erlang:sys-
                  tem_info(dirty_cpu_schedulers),                  erlang:sys-
                  tem_info(dirty_cpu_schedulers_online),    and    erlang:sys-
                  tem_flag(dirty_cpu_schedulers_online,  DirtyCPUSchedulersOn-
                  line).

                multi_scheduling:
                  Returns one of the following:

                  disabled:
                    The  emulator  has  been  started  with only one scheduler
                    thread.

                  blocked:
                    The emulator has more than one scheduler thread,  but  all
                    scheduler  threads  except  one are blocked. That is, only
                    one scheduler thread schedules Erlang processes  and  exe-
                    cutes Erlang code.

                  blocked_normal:
                    The  emulator  has more than one scheduler thread, but all
                    normal scheduler threads except one  are  blocked.  Notice
                    that  dirty  schedulers  are not blocked, and can schedule
                    Erlang processes and execute native code.

                  enabled:
                    The emulator has more than one scheduler  thread,  and  no
                    scheduler  threads  are  blocked.  That  is, all available
                    scheduler threads schedule Erlang  processes  and  execute
                    Erlang code.

                  See  also  erlang:system_flag(multi_scheduling, BlockState),
                  erlang:system_info(multi_scheduling_blockers),   erlang:sys-
                  tem_info(normal_multi_scheduling_blockers),  and erlang:sys-
                  tem_info(schedulers).

                multi_scheduling_blockers:
                  Returns a list of Pids  when  multi-scheduling  is  blocked,
                  otherwise  the  empty list is returned. The Pids in the list
                  represent all the processes currently blocking  multi-sched-
                  uling.  A Pid occurs only once in the list, even if the cor-
                  responding process has blocked multiple times.

                  See also  erlang:system_flag(multi_scheduling,  BlockState),
                  erlang:system_info(multi_scheduling),            erlang:sys-
                  tem_info(normal_multi_scheduling_blockers), and  erlang:sys-
                  tem_info(schedulers).

                normal_multi_scheduling_blockers:
                  Returns  a  list  of  Pids  when  normal multi-scheduling is
                  blocked (that is, all normal schedulers but one is blocked),
                  otherwise  the  empty list is returned. The Pids in the list
                  represent all the processes currently blocking normal multi-
                  scheduling.  A Pid occurs only once in the list, even if the
                  corresponding process has blocked multiple times.

                  See also  erlang:system_flag(multi_scheduling,  BlockState),
                  erlang:system_info(multi_scheduling),            erlang:sys-
                  tem_info(multi_scheduling_blockers),     and     erlang:sys-
                  tem_info(schedulers).

                scheduler_bind_type:
                  Returns  information about how the user has requested sched-
                  ulers to be bound or not bound.

                  Notice that although a user has requested schedulers  to  be
                  bound, they can silently have failed to bind. To inspect the
                  scheduler bindings, call  erlang:system_info(scheduler_bind-
                  ings).

                  For  more  information,  see  command-line  argument +sbt in
                  erl(1) and erlang:system_info(scheduler_bindings).

                scheduler_bindings:
                  Returns information about the currently used scheduler bind-
                  ings.

                  A tuple of a size equal to erlang:system_info(schedulers) is
                  returned. The tuple elements are integers or  the  atom  un-
                  bound.  Logical processor identifiers are represented as in-
                  tegers. The Nth element of  the  tuple  equals  the  current
                  binding  for  the  scheduler  with  the scheduler identifier
                  equal to N. For example, if the schedulers are  bound,  ele-
                  ment(erlang:system_info(scheduler_id),           erlang:sys-
                  tem_info(scheduler_bindings)) returns the identifier of  the
                  logical processor that the calling process is executing on.

                  Notice  that  only schedulers online can be bound to logical
                  processors.

                  For more information,  see  command-line  argument  +sbt  in
                  erl(1) and erlang:system_info(schedulers_online).

                scheduler_id:
                  Returns  the  scheduler  ID  (SchedulerId)  of the scheduler
                  thread that the calling process is executing on. SchedulerId
                  is a positive integer, where 1 <= SchedulerId <= erlang:sys-
                  tem_info(schedulers).

                  See also erlang:system_info(schedulers).

                schedulers:
                  Returns the number of scheduler threads used by  the  emula-
                  tor. Scheduler threads online schedules Erlang processes and
                  Erlang ports, and execute Erlang code and  Erlang  linked-in
                  driver code.

                  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.

                  See also erlang:system_flag(schedulers_online, SchedulersOn-
                  line),  erlang:system_info(schedulers_online),   erlang:sys-
                  tem_info(scheduler_id), erlang:system_flag(multi_scheduling,
                  BlockState),    erlang:system_info(multi_scheduling),    er-
                  lang:system_info(normal_multi_scheduling_blockers)  and  er-
                  lang:system_info(multi_scheduling_blockers).

                schedulers_online:
                  Returns the number of schedulers online. The scheduler iden-
                  tifiers  of  schedulers online satisfy the relationship 1 <=
                  SchedulerId <= erlang:system_info(schedulers_online).

                  For more information, see erlang:system_info(schedulers) and
                  erlang:system_flag(schedulers_online, SchedulersOnline).

                smp_support:
                  Returns true.

                threads:
                  Returns true.

                thread_pool_size:

                  Returns the number of async threads in the async thread pool
                  used       for       asynchronous        driver        calls
                  (erl_driver:driver_async()).  The value is given as an inte-
                  ger.

       erlang:system_info(Item :: creation) -> integer()

       erlang:system_info(Item :: delayed_node_table_gc) ->
                             infinity | integer() >= 0

       erlang:system_info(Item :: dist) -> binary()

       erlang:system_info(Item :: dist_buf_busy_limit) ->
                             integer() >= 0

       erlang:system_info(Item :: dist_ctrl) ->
                             {Node :: node(),
                              ControllingEntity :: port() | pid()}

              Returns information about Erlang  Distribution  in  the  current
              system as specified by Item:

                creation:
                  Returns  the  creation  of the local node as an integer. The
                  creation is changed when a node is restarted.  The  creation
                  of  a  node  is  stored in process identifiers, port identi-
                  fiers, and references. This makes it (to some extent) possi-
                  ble to distinguish between identifiers from different incar-
                  nations of a node. The valid creations are integers  in  the
                  range  1..3,  but  this will probably change in a future re-
                  lease. If the node is not alive, 0 is returned.

                delayed_node_table_gc:
                  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 command-line flag +zdntgc  to  erl(1).
                  For  more information, see the documentation of the command-
                  line flag.

                dist:
                  Returns a binary containing a string of distribution  infor-
                  mation formatted as in Erlang crash dumps. For more informa-
                  tion, see section  How to interpret the Erlang  crash  dumps
                  in the User's Guide.

                dist_buf_busy_limit:
                  Returns  the  value of the distribution buffer busy limit in
                  bytes. This limit can be set at startup by passing  command-
                  line flag +zdbbl to erl(1).

                dist_ctrl:
                  Returns  a list of tuples {Node, ControllingEntity}, one en-
                  try for each connected remote node. Node is  the  node  name
                  and  ControllingEntity is the port or process identifier re-
                  sponsible for the communication to that node. More  specifi-
                  cally,  ControllingEntity for nodes connected through TCP/IP
                  (the normal case) is the socket used in  communication  with
                  the specific node.

       erlang:system_info(Item :: build_type) ->
                             opt | debug | purify | quantify | purecov |
                             gcov | valgrind | gprof | lcnt | frmptr

       erlang:system_info(Item :: c_compiler_used) -> {atom(), term()}

       erlang:system_info(Item :: check_io) -> [term()]

       erlang:system_info(Item :: compat_rel) -> integer()

       erlang:system_info(Item :: debug_compiled) -> boolean()

       erlang:system_info(Item :: driver_version) -> string()

       erlang:system_info(Item :: dynamic_trace) ->
                             none | dtrace | systemtap

       erlang:system_info(Item :: dynamic_trace_probes) -> boolean()

       erlang:system_info(Item :: info) -> binary()

       erlang:system_info(Item :: kernel_poll) -> boolean()

       erlang:system_info(Item :: loaded) -> binary()

       erlang:system_info(Item :: machine) -> string()

       erlang:system_info(Item :: modified_timing_level) ->
                             integer() | undefined

       erlang:system_info(Item :: nif_version) -> string()

       erlang:system_info(Item :: otp_release) -> string()

       erlang:system_info(Item :: port_parallelism) -> boolean()

       erlang:system_info(Item :: system_architecture) -> string()

       erlang:system_info(Item :: system_logger) ->
                             logger | undefined | pid()

       erlang:system_info(Item :: system_version) -> string()

       erlang:system_info(Item :: trace_control_word) ->
                             integer() >= 0

       erlang:system_info(Item :: version) -> string()

       erlang:system_info(Item ::
                              wordsize |
                              {wordsize, internal} |
                              {wordsize, external}) ->
                             4 | 8

              Returns  various information about the current system (emulator)
              as specified by Item:

                build_type:
                  Returns an atom describing the build  type  of  the  runtime
                  system.  This  is normally the atom opt for optimized. Other
                  possible return values are debug, purify, quantify, purecov,
                  gcov,  valgrind, gprof, and lcnt. Possible return values can
                  be added or removed at any time without prior notice.

                c_compiler_used:
                  Returns a two-tuple describing the C compiler used when com-
                  piling  the runtime system. The first element is an atom de-
                  scribing the name of the compiler, or undefined if  unknown.
                  The  second  element is a term describing the version of the
                  compiler, or undefined if unknown.

                check_io:
                  Returns a list containing  miscellaneous  information  about
                  the emulators internal I/O checking. Notice that the content
                  of the returned list can vary  between  platforms  and  over
                  time. It is only guaranteed that a list is returned.

                compat_rel:
                  Returns the compatibility mode of the local node as an inte-
                  ger. The integer returned represents the Erlang/OTP  release
                  that  the  current emulator has been set to be backward com-
                  patible with. The compatibility mode can  be  configured  at
                  startup by using command-line flag +R in erl(1).

                debug_compiled:
                  Returns true if the emulator has been debug-compiled, other-
                  wise false.

                driver_version:
                  Returns a string containing the Erlang driver  version  used
                  by  the runtime system. It has the form  "<major ver>.<minor
                  ver>".

                dynamic_trace:
                  Returns an atom describing the dynamic trace framework  com-
                  piled into the virtual machine. It can be dtrace, systemtap,
                  or none. For a commercial or standard build,  it  is  always
                  none.  The  other return values indicate a custom configura-
                  tion (for example, ./configure --with-dynamic-trace=dtrace).
                  For   more  information  about  dynamic  tracing,  see  dyn-
                  trace(3erl) manual page and the README.dtrace/README.system-
                  tap files in the Erlang source code top directory.

                dynamic_trace_probes:
                  Returns  a  boolean()  indicating  if  dynamic  trace probes
                  (dtrace or systemtap) are built into the emulator. This  can
                  only  be  true  if the virtual machine was built for dynamic
                  tracing (that is, system_info(dynamic_trace) returns  dtrace
                  or systemtap).

                info:
                  Returns a binary containing a string of miscellaneous system
                  information formatted as in Erlang crash dumps. For more in-
                  formation,  see  section   How to interpret the Erlang crash
                  dumps in the User's Guide.

                kernel_poll:
                  Returns true if the emulator uses some kind  of  kernel-poll
                  implementation, otherwise false.

                loaded:
                  Returns a binary containing a string of loaded module infor-
                  mation formatted as in Erlang crash dumps. For more informa-
                  tion, see section How to interpret the Erlang crash dumps in
                  the User's Guide.

                machine:
                  Returns a string containing the Erlang machine name.

                modified_timing_level:
                  Returns the modified timing-level (an integer)  if  modified
                  timing is enabled, otherwise undefined. For more information
                  about modified timing, see command-line flag +T in erl(1)

                nif_version:
                  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>".

                otp_release:

                  Returns a string containing the OTP release  number  of  the
                  OTP release that the currently executing ERTS application is
                  part of.

                  As from Erlang/OTP 17, the OTP release number corresponds to
                  the  major OTP version number. No erlang:system_info() argu-
                  ment 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
                  System principles in System Documentation.

                port_parallelism:
                  Returns  the  default port parallelism scheduling hint used.
                  For more information,  see  command-line  argument  +spp  in
                  erl(1).

                system_architecture:
                  Returns  a  string containing the processor and OS architec-
                  ture the emulator is built for.

                system_logger:
                  Returns the current  system_logger  as  set  by  erlang:sys-
                  tem_flag(system_logger, _).

                system_version:
                  Returns  a  string containing version number and some impor-
                  tant properties, such as the number of schedulers.

                trace_control_word:
                  Returns the value of the node trace control word.  For  more
                  information, see function get_tcw in section  Match Specifi-
                  cations in Erlang in the User's Guide.

                version:
                  Returns a string containing the version number of the emula-
                  tor.

                wordsize:
                  Same as {wordsize, internal}.

                {wordsize, internal}:
                  Returns  the  size of Erlang term words in bytes as an inte-
                  ger, that is, 4 is returned on a 32-bit architecture, and  8
                  is  returned  on  a  pure 64-bit architecture. On a halfword
                  64-bit emulator, 4 is returned,  as  the  Erlang  terms  are
                  stored  using  a  virtual  word size of half the system word
                  size.

                {wordsize, external}:
                  Returns the true word size of the  emulator,  that  is,  the
                  size  of  a pointer. The value is given in bytes as an inte-
                  ger. On a pure 32-bit architecture, 4 is returned. On both a
                  half word and on a pure 64-bit architecture, 8 is returned.

       erlang:system_monitor() -> MonSettings

              Types:

                 MonSettings = undefined | {MonitorPid, Options}
                 MonitorPid = pid()
                 Options = [system_monitor_option()]
                 system_monitor_option() =
                     busy_port | busy_dist_port |
                     {long_gc, integer() >= 0} |
                     {long_schedule, integer() >= 0} |
                     {large_heap, integer() >= 0}

              Returns  the  current  system  monitoring  settings  set  by er-
              lang:system_monitor/2 as {MonitorPid, Options}, or undefined  if
              no  settings  exist.  The  order of the options can be different
              from the one that was set.

       erlang:system_monitor(Arg) -> MonSettings

              Types:

                 Arg = MonSettings = undefined | {MonitorPid, Options}
                 MonitorPid = pid()
                 Options = [system_monitor_option()]
                 system_monitor_option() =
                     busy_port | busy_dist_port |
                     {long_gc, integer() >= 0} |
                     {long_schedule, integer() >= 0} |
                     {large_heap, integer() >= 0}

              When called with argument undefined, all system performance mon-
              itoring settings are cleared.

              Calling  the  function with {MonitorPid, Options} as argument is
              the same as calling erlang:system_monitor(MonitorPid, Options).

              Returns the previous  system  monitor  settings  just  like  er-
              lang:system_monitor/0.

       erlang:system_monitor(MonitorPid, Options) -> MonSettings

              Types:

                 MonitorPid = pid()
                 Options = [system_monitor_option()]
                 MonSettings = undefined | {OldMonitorPid, OldOptions}
                 OldMonitorPid = pid()
                 OldOptions = [system_monitor_option()]
                 system_monitor_option() =
                     busy_port | busy_dist_port |
                     {long_gc, integer() >= 0} |
                     {long_schedule, integer() >= 0} |
                     {large_heap, integer() >= 0}

              Sets  the system performance monitoring options. MonitorPid is a
              local process identifier (pid)  receiving  system  monitor  mes-
              sages. The second argument is a list of monitoring options:

                {long_gc, Time}:
                  If  a  garbage  collection in the system takes at least Time
                  wall clock milliseconds, a message {monitor, GcPid, long_gc,
                  Info}  is  sent  to  MonitorPid.  GcPid  is the pid that was
                  garbage collected. Info is a list of two-element tuples  de-
                  scribing the result of the garbage collection.

                  One  of the tuples is {timeout, GcTime}, where GcTime is the
                  time for the garbage collection in milliseconds.  The  other
                  tuples   are   tagged   with   heap_size,   heap_block_size,
                  stack_size,       mbuf_size,       old_heap_size,        and
                  old_heap_block_size.  These  tuples are explained in the de-
                  scription  of  trace   message   gc_minor_start   (see   er-
                  lang:trace/3). New tuples can be added, and the order of the
                  tuples in the Info list can be changed at any  time  without
                  prior notice.

                {long_schedule, Time}:
                  If a process or port in the system runs uninterrupted for at
                  least Time wall clock milliseconds, a message {monitor,  Pi-
                  dOrPort,  long_schedule, Info} is sent to MonitorPid. PidOr-
                  Port is the process or port that was running. Info is a list
                  of two-element tuples describing the event.

                  If  a  pid(),  the tuples {timeout, Millis}, {in, Location},
                  and {out, Location} are present, where Location is either an
                  MFA  ({Module,  Function,  Arity})  describing  the function
                  where the process was scheduled in/out, or  the  atom  unde-
                  fined.

                  If  a  port(), the tuples {timeout, Millis} and {port_op,Op}
                  are present. Op is one of proc_sig, timeout, input,  output,
                  event,  or  dist_cmd, depending on which driver callback was
                  executing.

                  proc_sig is an internal operation and is  never  to  appear,
                  while  the  others  represent the corresponding driver call-
                  backs timeout, ready_input, ready_output, event, and outputv
                  (when the port is used by distribution). Value Millis in tu-
                  ple timeout informs about the uninterrupted  execution  time
                  of  the  process or port, which always is equal to or higher
                  than the Time value supplied when starting  the  trace.  New
                  tuples  can  be  added to the Info list in a future release.
                  The order of the tuples in the list can be  changed  at  any
                  time without prior notice.

                  This  can  be  used  to detect problems with NIFs or 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 <  100
                  ms as "possible" and fairly "normal". However, longer sched-
                  ule times can indicate swapping or a misbehaving NIF/driver.
                  Misbehaving NIFs and drivers can cause bad resource utiliza-
                  tion and bad overall system performance.

                {large_heap, Size}:
                  If a garbage collection in the system results in  the  allo-
                  cated  size  of  a heap being at least Size words, a message
                  {monitor, GcPid, large_heap, Info} is  sent  to  MonitorPid.
                  GcPid  and  Info are the same as for long_gc earlier, except
                  that the tuple tagged with timeout is not present.

                  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 Size.

                  When a process is killed by max_heap_size, it is killed  be-
                  fore  the  garbage  collection is complete and thus no large
                  heap message is sent.

                busy_port:
                  If a process in the system gets suspended because  it  sends
                  to a busy port, a message {monitor, SusPid, busy_port, Port}
                  is sent to MonitorPid. SusPid is the pid that got  suspended
                  when sending to Port.

                busy_dist_port:
                  If  a  process in the system gets suspended because it sends
                  to a process on a remote node whose inter-node communication
                  was  handled  by  a  busy  port, a message {monitor, SusPid,
                  busy_dist_port, Port} is sent to MonitorPid. SusPid  is  the
                  pid  that  got suspended when sending through the inter-node
                  communication port Port.

              Returns the previous  system  monitor  settings  just  like  er-
              lang:system_monitor/0.

              The arguments to system_monitor/2 specifies how all system moni-
              toring on the node should be done, not how it should be changed.
              This  means  only  one process at a time (MonitorPid) can be the
              receiver of system monitor messages. Also, the way  to  clear  a
              specific  monitor  option  is  to not include it in the list Op-
              tions. All system monitoring will, however, be  cleared  if  the
              process identified by MonitorPid terminates.

              There  are  no special option values (like zero) to clear an op-
              tion. Some of the options  have  a  unspecified  minimum  value.
              Lower values will be adjusted to the minimum value. For example,
              it is currently not possible to monitor all garbage  collections
              with {long_gc, 0}.

          Note:
              If  a  monitoring process gets so large that it itself starts to
              cause system monitor messages when garbage collecting, the  mes-
              sages  enlarge  the  process message queue and probably make the
              problem worse.

              Keep the monitoring process neat and do not set the system moni-
              tor limits too tight.

              Failures:

                badarg:
                  If MonitorPid does not exist.

                badarg:
                  If MonitorPid is not a local process.

       erlang:system_profile() -> ProfilerSettings

              Types:

                 ProfilerSettings = undefined | {ProfilerPid, Options}
                 ProfilerPid = pid() | port()
                 Options = [system_profile_option()]
                 system_profile_option() =
                     exclusive | runnable_ports | runnable_procs | scheduler |
                     timestamp | monotonic_timestamp | strict_monotonic_timestamp

              Returns the current system profiling settings set by erlang:sys-
              tem_profile/2 as {ProfilerPid, Options}, or undefined  if  there
              are  no settings. The order of the options can be different from
              the one that was set.

       erlang:system_profile(ProfilerPid, Options) -> ProfilerSettings

              Types:

                 ProfilerPid = pid() | port() | undefined
                 Options = [system_profile_option()]
                 ProfilerSettings =
                     undefined | {pid() | port(), [system_profile_option()]}
                 system_profile_option() =
                     exclusive | runnable_ports | runnable_procs | scheduler |
                     timestamp | monotonic_timestamp | strict_monotonic_timestamp

              Sets system profiler options. ProfilerPid  is  a  local  process
              identifier  (pid)  or port receiving profiling messages. The re-
              ceiver is excluded from all profiling. The second argument is  a
              list of profiling options:

                exclusive:
                  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 in-
                  active, and later active when the port callback returns.

                monotonic_timestamp:
                  Time stamps in profile messages use Erlang  monotonic  time.
                  The  time  stamp  (Ts) has the same format and value as pro-
                  duced by erlang:monotonic_time(nanosecond).

                runnable_procs:
                  If a process is put into or removed from the  run  queue,  a
                  message,  {profile, Pid, State, Mfa, Ts}, is sent to Profil-
                  erPid. Running processes that are reinserted  into  the  run
                  queue  after having been pre-empted do not trigger this mes-
                  sage.

                runnable_ports:
                  If a port is put into or removed from the run queue, a  mes-
                  sage, {profile, Port, State, 0, Ts}, is sent to ProfilerPid.

                scheduler:
                  If  a  scheduler is put to sleep or awoken, a message, {pro-
                  file, scheduler, Id, State, NoScheds, Ts}, is sent  to  Pro-
                  filerPid.

                strict_monotonic_timestamp:
                  Time  stamps in profile messages consist of Erlang monotonic
                  time and a monotonically increasing integer. The time  stamp
                  (Ts)  has  the  same  format  and  value as produced by {er-
                  lang:monotonic_time(nanosecond),         erlang:unique_inte-
                  ger([monotonic])}.

                timestamp:
                  Time  stamps  in  profile messages include a time stamp (Ts)
                  that has the same form as returned by erlang:now(). This  is
                  also  the  default  if  no  time stamp flag is specified. If
                  cpu_timestamp has been enabled through erlang:trace/3,  this
                  also  effects  the time stamp produced in profiling messages
                  when flag timestamp is enabled.

          Note:
              erlang:system_profile behavior can change in a future release.

       erlang:system_time() -> integer()

              Returns current  Erlang system time in native time unit.

              Calling  erlang:system_time()  is  equivalent  to   erlang:mono-
              tonic_time() + erlang:time_offset().

          Note:
              This  time is not a monotonically increasing time in the general
              case. For more information, see the documentation of  time  warp
              modes in the User's Guide.

       erlang:system_time(Unit) -> integer()

              Types:

                 Unit = time_unit()

              Returns  current   Erlang  system  time  converted into the Unit
              passed as argument.

              Calling erlang:system_time(Unit) is  equivalent  to  erlang:con-
              vert_time_unit(erlang:system_time(), native, Unit).

          Note:
              This  time is not a monotonically increasing time in the general
              case. For more information, see the documentation of  time  warp
              modes in the User's Guide.

       term_to_binary(Term) -> ext_binary()

              Types:

                 Term = term()

              Returns a binary data object that is the result of encoding Term
              according to the Erlang external term format.

              This can be used for various purposes, for  example,  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.

              > Bin = term_to_binary(hello).
              <<131,100,0,5,104,101,108,108,111>>
              > hello = binary_to_term(Bin).
              hello

              See also binary_to_term/1.

          Note:
              There  is  no  guarantee that this function will return the same
              encoded representation for the same term.

       term_to_binary(Term, Options) -> ext_binary()

              Types:

                 Term = term()
                 Options =
                     [compressed |
                      {compressed, Level :: 0..9} |
                      {minor_version, Version :: 0..2}]

              Returns a binary data object that is the result of encoding Term
              according to the Erlang external term format.

              If  option  compressed  is provided, the external term format is
              compressed. The compressed format is automatically recognized by
              binary_to_term/1 as from Erlang/OTP R7B.

              A  compression  level  can  be  specified by giving option {com-
              pressed, Level}. Level is an integer with range 0..9, where:

                * 0 - No compression is done (it is the same as giving no com-
                  pressed option).

                * 1  -  Takes  least  time but may not compress as well as the
                  higher levels.

                * 6 - Default level when option compressed is provided.

                * 9 - 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 pro-
                  duce a smaller result than level 1 compression.

              Option  {minor_version, Version} can be used to control some en-
              coding details. This option was introduced in Erlang/OTP R11B-4.
              The valid values for Version are:

                0:
                  Floats  are encoded using a textual representation. This op-
                  tion is useful to ensure  that  releases  before  Erlang/OTP
                  R11B-4 can decode resulting binary.

                  This  version  encode  atoms  that  can  be represented by a
                  latin1 string using latin1 encoding while  only  atoms  that
                  cannot be represented by latin1 are encoded using utf8.

                1:
                  This  is  as  of  Erlang/OTP 17.0 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). As  from  Erlang/OTP
                  R11B-4, binary_to_term/1 can decode this representation.

                  This  version  encode  atoms  that  can  be represented by a
                  latin1 string using latin1 encoding while  only  atoms  that
                  cannot be represented by latin1 are encoded using utf8.

                2:
                  Drops  usage of the latin1 atom encoding and unconditionally
                  use utf8 encoding for all atoms. This will be changed to the
                  default  in a future major release of Erlang/OTP. Erlang/OTP
                  systems as of R16B can decode this representation.

              See also binary_to_term/1.

       term_to_iovec(Term) -> ext_iovec()

              Types:

                 Term = term()

              Returns the encoding of Term according to  the  Erlang  external
              term format as ext_iovec().

              This function produce the same encoding as term_to_binary/1, but
              with   another   return    type.    The    call    iolist_to_bi-
              nary(term_to_iovec(Term))  will  produce exactly the same result
              as the call term_to_binary(Term).

              term_to_iovec() is a  pure  optimization  of  the  functionality
              term_to_binary()  provide. term_to_iovec() can for example refer
              directly to off heap binaries instead of copying the binary data
              into the result.

              See also term_to_binary/1.

       term_to_iovec(Term, Options) -> ext_iovec()

              Types:

                 Term = term()
                 Options =
                     [compressed |
                      {compressed, Level :: 0..9} |
                      {minor_version, Version :: 0..2}]

              Returns  the  encoding  of Term according to the Erlang external
              term format as ext_iovec().

              This function produce the same encoding as term_to_binary/2, but
              with    another    return    type.    The   call   iolist_to_bi-
              nary(term_to_iovec(Term, Opts)) will produce  exactly  the  same
              result as term_to_binary(Term, Opts).

              Currently  recognised  options  are  all  options  recognised by
              term_to_binary/2.

              term_to_iovec() is a  pure  optimization  of  the  functionality
              term_to_binary()  provide. term_to_iovec() can for example refer
              directly to off heap binaries instead of copying the binary data
              into the result.

              See also term_to_binary/2.

       throw(Any) -> no_return()

              Types:

                 Any = term()

              A non-local return from a function. If evaluated within a catch,
              catch returns value Any. Example:

              > catch throw({hello, there}).
              {hello,there}

              Failure: nocatch if not evaluated within a catch.

       time() -> Time

              Types:

                 Time = calendar:time()

              Returns the current time as {Hour, Minute, Second}.

              The time zone and Daylight Saving Time correction depend on  the
              underlying OS. Example:

              > time().
              {9,42,44}

       erlang:time_offset() -> integer()

              Returns  the  current time offset between  Erlang monotonic time
              and  Erlang system time in native time unit. Current time offset
              added  to  an  Erlang  monotonic time gives corresponding Erlang
              system time.

              The time offset may or may not change during operation depending
              on the time warp mode used.

          Note:
              A  change  in  time offset can be observed at slightly different
              points in time by different processes.

              If the runtime system is in multi-time warp mode, the time  off-
              set  is changed when the runtime system detects that the OS sys-
              tem time has changed. The runtime system will, however, not  de-
              tect  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.

       erlang:time_offset(Unit) -> integer()

              Types:

                 Unit = time_unit()

              Returns the current time offset between  Erlang  monotonic  time
              and   Erlang system time converted into the Unit passed as argu-
              ment.

              Same as  calling  erlang:convert_time_unit(erlang:time_offset(),
              native, Unit) however optimized for commonly used Units.

       erlang:timestamp() -> Timestamp

              Types:

                 Timestamp = timestamp()
                 timestamp() =
                     {MegaSecs :: integer() >= 0,
                      Secs :: integer() >= 0,
                      MicroSecs :: integer() >= 0}

              Returns  current   Erlang  system  time on the format {MegaSecs,
              Secs, MicroSecs}. This format is the same as os:timestamp/0  and
              the deprecated erlang:now/0 use. The reason for the existence of
              erlang:timestamp() 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 erlang:system_time/1.

              The erlang:timestamp() BIF is equivalent to:

              timestamp() ->
                  ErlangSystemTime = erlang:system_time(microsecond),
                  MegaSecs = ErlangSystemTime div 1000000000000,
                  Secs = ErlangSystemTime div 1000000 - MegaSecs*1000000,
                  MicroSecs = ErlangSystemTime rem 1000000,
                  {MegaSecs, Secs, MicroSecs}.

              It,  however,  uses  a native implementation that does not build
              garbage on the heap and with slightly better performance.

          Note:
              This time is not a monotonically increasing time in the  general
              case.  For more information, see the documentation of  time warp
              modes in the User's Guide.

       tl(List) -> term()

              Types:

                 List = [term(), ...]

              Returns the tail of List, that is, the list minus the first ele-
              ment, for example:

              > tl([geesties, guilies, beasties]).
              [guilies, beasties]

              Allowed in guard tests.

              Failure: badarg if List is the empty list [].

       erlang:trace(PidPortSpec, How, FlagList) -> integer()

              Types:

                 PidPortSpec =
                     pid() |
                     port() |
                     all | processes | ports | existing | existing_processes |
                     existing_ports | new | new_processes | new_ports
                 How = boolean()
                 FlagList = [trace_flag()]
                 trace_flag() =
                     all | send | 'receive' | procs | ports | call | arity |
                     return_to | silent | running | exiting | running_procs |
                     running_ports | garbage_collection | timestamp |
                     cpu_timestamp | monotonic_timestamp |
                     strict_monotonic_timestamp | set_on_spawn |
                     set_on_first_spawn | set_on_link | set_on_first_link |
                     {tracer, pid() | port()} |
                     {tracer, module(), term()}

              Turns  on  (if  How  == true) or off (if How == false) the trace
              flags in FlagList for the process or  processes  represented  by
              PidPortSpec.

              PidPortSpec  is  either  a  process identifier (pid) for a local
              process, a port identifier, or one of the following atoms:

                all:
                  All currently existing processes and ports and all that will
                  be created in the future.

                processes:
                  All  currently  existing processes and all that will be cre-
                  ated in the future.

                ports:
                  All currently existing ports and all that will be created in
                  the future.

                existing:
                  All currently existing processes and ports.

                existing_processes:
                  All currently existing processes.

                existing_ports:
                  All currently existing ports.

                new:
                  All processes and ports that will be created in the future.

                new_processes:
                  All processes that will be created in the future.

                new_ports:
                  All ports that will be created in the future.

              FlagList  can  contain  any  number  of the following flags (the
              "message tags" refers to the list of trace messages):

                all:
                  Sets all trace flags except tracer and cpu_timestamp,  which
                  are in their nature different than the others.

                send:
                  Traces sending of messages.

                  Message tags: send and send_to_non_existing_process.

                'receive':
                  Traces receiving of messages.

                  Message tags: 'receive'.

                call:
                  Traces  certain function calls. Specify which function calls
                  to trace by calling erlang:trace_pattern/3.

                  Message tags: call and return_from.

                silent:
                  Used with the call trace flag. The  call,  return_from,  and
                  return_to  trace messages are inhibited if this flag is set,
                  but they are executed as normal if there are match  specifi-
                  cations.

                  Silent mode is inhibited by executing erlang:trace(_, false,
                  [silent|_]), or by a match specification executing the func-
                  tion {silent, false}.

                  The silent trace flag facilitates setting up a trace on many
                  or even all processes in the system. The trace can  then  be
                  activated  and  deactivated  using  the  match specification
                  function {silent,Bool}, giving a high degree of  control  of
                  which functions with which arguments that trigger the trace.

                  Message  tags:  call, return_from, and return_to. Or rather,
                  the absence of.

                return_to:
                  Used with the call trace flag.  Traces  the  return  from  a
                  traced function back to its caller. Only works for functions
                  traced with option local to erlang:trace_pattern/3.

                  The semantics is that a trace message is sent  when  a  call
                  traced  function  returns, that is, when a chain of tail re-
                  cursive calls ends. Only one trace message is sent per chain
                  of  tail  recursive  calls, so the properties of tail recur-
                  siveness for function calls are kept while tracing with this
                  flag.  Using call and return_to trace together makes it pos-
                  sible to know exactly in which function a  process  executes
                  at any time.

                  To  get  trace  messages containing return values from func-
                  tions, use the {return_trace} match specification action in-
                  stead.

                  Message tags: return_to.

                procs:
                  Traces process-related events.

                  Message  tags:  spawn,  spawned, exit, register, unregister,
                  link, unlink, getting_linked, and getting_unlinked.

                ports:
                  Traces port-related events.

                  Message  tags:  open,  closed,  register,  unregister,  get-
                  ting_linked, and getting_unlinked.

                running:
                  Traces scheduling of processes.

                  Message tags: in and out.

                exiting:
                  Traces scheduling of exiting processes.

                  Message tags: in_exiting, out_exiting, and out_exited.

                running_procs:
                  Traces  scheduling  of processes just like running. However,
                  this option also includes schedule events when  the  process
                  executes  within  the context of a port without being sched-
                  uled out itself.

                  Message tags: in and out.

                running_ports:
                  Traces scheduling of ports.

                  Message tags: in and out.

                garbage_collection:
                  Traces garbage collections of processes.

                  Message tags: gc_minor_start, gc_max_heap_size,  and  gc_mi-
                  nor_end.

                timestamp:
                  Includes  a time stamp in all trace messages. The time stamp
                  (Ts) has the same form as returned by erlang:now().

                cpu_timestamp:
                  A global trace flag for the Erlang node that makes all trace
                  time stamps using flag timestamp to be in CPU time, not wall
                  clock time. That is, cpu_timestamp is not be used  if  mono-
                  tonic_timestamp  or  strict_monotonic_timestamp  is enabled.
                  Only allowed with PidPortSpec==all. If the host  machine  OS
                  does  not  support  high-resolution  CPU  time measurements,
                  trace/3 exits with badarg. Notice that most OS do  not  syn-
                  chronize  this  value across cores, so be prepared that time
                  can seem to go backwards when using this option.

                monotonic_timestamp:
                  Includes an Erlang monotonic time time stamp  in  all  trace
                  messages.  The time stamp (Ts) has the same format and value
                  as produced by erlang:monotonic_time(nanosecond). This  flag
                  overrides flag cpu_timestamp.

                strict_monotonic_timestamp:
                  Includes  an  time stamp consisting of Erlang monotonic time
                  and a monotonically increasing integer  in  all  trace  mes-
                  sages.  The time stamp (Ts) has the same format and value as
                  produced   by   {   erlang:monotonic_time(nanosecond),   er-
                  lang:unique_integer([monotonic])}.  This flag overrides flag
                  cpu_timestamp.

                arity:
                  Used with the call trace flag. {M, F,  Arity}  is  specified
                  instead of {M, F, Args} in call trace messages.

                set_on_spawn:
                  Makes  any  process  created by a traced process inherit its
                  trace flags, including flag set_on_spawn.

                set_on_first_spawn:
                  Makes the first process created by a traced process  inherit
                  its trace flags, excluding flag set_on_first_spawn.

                set_on_link:
                  Makes  any  process  linked  by a traced process inherit its
                  trace flags, including flag set_on_link.

                set_on_first_link:
                  Makes the first process linked to by a  traced  process  in-
                  herit its trace flags, excluding flag set_on_first_link.

                {tracer, Tracer}:
                  Specifies  where  to send the trace messages. Tracer must be
                  the process identifier of a local process or the port  iden-
                  tifier of a local port.

                {tracer, TracerModule, TracerState}:
                  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 erl_tracer(3erl).

              If no tracer is specified, the calling process receives all  the
              trace messages.

              The  effect  of  combining set_on_first_link with set_on_link is
              the same as set_on_first_link alone. Likewise  for  set_on_spawn
              and set_on_first_spawn.

              The tracing process receives the trace messages described in the
              following list. Pid is the  process  identifier  of  the  traced
              process  in which the traced event has occurred. The third tuple
              element is the message tag.

              If  flag   timestamp,   strict_monotonic_timestamp,   or   mono-
              tonic_timestamp   is  specified,  the  first  tuple  element  is
              trace_ts instead, and the time stamp is added as an  extra  ele-
              ment last in the message tuple. If multiple time stamp flags are
              passed, timestamp  has  precedence  over  strict_monotonic_time-
              stamp,  which  in  turn has precedence over monotonic_timestamp.
              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.

              If a match specification (applicable only  for  call,  send  and
              'receive'  tracing)  contains a {message} action function with a
              non-boolean value, that value is added as an  extra  element  to
              the  message  tuple  either  in  the last position or before the
              timestamp (if it is present).

              Trace messages:

                {trace, PidPort, send, Msg, To}:
                  When PidPort sends message Msg to process To.

                {trace, PidPort, send_to_non_existing_process, Msg, To}:
                  When PidPort sends message Msg to the  non-existing  process
                  To.

                {trace, PidPort, 'receive', Msg}:
                  When  PidPort  receives  message Msg. If Msg is set to time-
                  out, a receive statement can have timed out, or the  process
                  received a message with the payload timeout.

                {trace, Pid, call, {M, F, Args}}:
                  When Pid calls a traced function. The return values of calls
                  are never supplied, only the call and its arguments.

                  Trace flag arity can be used to change the contents of  this
                  message, so that Arity is specified instead of Args.

                {trace, Pid, return_to, {M, F, Arity}}:
                  When  Pid returns to the specified function. This trace mes-
                  sage is sent if both the flags call and return_to  are  set,
                  and  the  function  is  set  to  be traced on local function
                  calls. The message is only sent when returning from a  chain
                  of  tail  recursive  function calls, where at least one call
                  generated a call trace message (that is, the functions match
                  specification  matched,  and {message, false} was not an ac-
                  tion).

                {trace, Pid, return_from, {M, F, Arity}, ReturnValue}:
                  When Pid returns from the  specified  function.  This  trace
                  message  is sent if flag call is set, and the function has a
                  match specification with a return_trace  or  exception_trace
                  action.

                {trace, Pid, exception_from, {M, F, Arity}, {Class, Value}}:
                  When Pid exits from the specified function because of an ex-
                  ception. This trace message is sent if flag call is set, and
                  the  function  has  a  match  specification  with  an excep-
                  tion_trace action.

                {trace, Pid, spawn, Pid2, {M, F, Args}}:
                  When Pid spawns a new process Pid2 with the specified  func-
                  tion call as entry point.

                  Args  is  supposed  to  be the argument list, but can be any
                  term if the spawn is erroneous.

                {trace, Pid, spawned, Pid2, {M, F, Args}}:
                  When Pid is spawned by process Pid2 with the specified func-
                  tion call as entry point.

                  Args  is  supposed  to  be the argument list, but can be any
                  term if the spawn is erroneous.

                {trace, Pid, exit, Reason}:
                  When Pid exits with reason Reason.

                {trace, PidPort, register, RegName}:
                  When PidPort gets the name RegName registered.

                {trace, PidPort, unregister, RegName}:
                  When PidPort gets the name  RegName  unregistered.  This  is
                  done automatically when a registered process or port exits.

                {trace, Pid, link, Pid2}:
                  When Pid links to a process Pid2.

                {trace, Pid, unlink, Pid2}:
                  When Pid removes the link from a process Pid2.

                {trace, PidPort, getting_linked, Pid2}:
                  When PidPort gets linked to a process Pid2.

                {trace, PidPort, getting_unlinked, Pid2}:
                  When PidPort gets unlinked from a process Pid2.

                {trace, Pid, exit, Reason}:
                  When Pid exits with reason Reason.

                {trace, Port, open, Pid, Driver}:
                  When Pid opens a new port Port with the running Driver.

                  Driver is the name of the driver as an atom.

                {trace, Port, closed, Reason}:
                  When Port closes with Reason.

                {trace, Pid, in | in_exiting, {M, F, Arity} | 0}:
                  When  Pid  is scheduled to run. The process runs in function
                  {M, F, Arity}. On some rare occasions, the current  function
                  cannot be determined, then the last element is 0.

                {trace,  Pid,  out | out_exiting | out_exited, {M, F, Arity} |
                0}:
                  When Pid is scheduled out. The process was running in  func-
                  tion  {M,  F,  Arity}.  On  some rare occasions, the current
                  function cannot be determined, then the last element is 0.

                {trace, Port, in, Command | 0}:
                  When Port is scheduled to run. Command is  the  first  thing
                  the  port  will execute, it can however run several commands
                  before being scheduled out. On some rare occasions, the cur-
                  rent function cannot be determined, then the last element is
                  0.

                  The possible commands are  call,  close,  command,  connect,
                  control, flush, info, link, open, and unlink.

                {trace, Port, out, Command | 0}:
                  When  Port  is  scheduled out. The last command run was Com-
                  mand. On some rare occasions, the current function cannot be
                  determined,  then the last element is 0. Command can contain
                  the same commands as in

                {trace, Pid, gc_minor_start, Info}:

                  Sent when a young garbage collection is about to be started.
                  Info  is  a list of two-element tuples, where the first ele-
                  ment is a key, and the second is the value. Do not depend on
                  any order of the tuples. The following keys are defined:

                  heap_size:
                    The size of the used part of the heap.

                  heap_block_size:
                    The size of the memory block used for storing the heap and
                    the stack.

                  old_heap_size:
                    The size of the used part of the old heap.

                  old_heap_block_size:
                    The size of the memory block  used  for  storing  the  old
                    heap.

                  stack_size:
                    The size of the stack.

                  recent_size:
                    The  size  of  the data that survived the previous garbage
                    collection.

                  mbuf_size:
                    The combined size of message buffers associated  with  the
                    process.

                  bin_vheap_size:
                    The total size of unique off-heap binaries referenced from
                    the process heap.

                  bin_vheap_block_size:
                    The total size of binaries allowed in the virtual heap  in
                    the process before doing a garbage collection.

                  bin_old_vheap_size:
                    The total size of unique off-heap binaries referenced from
                    the process old heap.

                  bin_old_vheap_block_size:
                    The total size of binaries allowed in the virtual old heap
                    in the process before doing a garbage collection.

                  All sizes are in words.

                {trace, Pid, gc_max_heap_size, Info}:
                  Sent  when  the max_heap_size is reached during garbage col-
                  lection. Info contains the same kind of list as  in  message
                  gc_start,  but  the  sizes  reflect the sizes that triggered
                  max_heap_size to be reached.

                {trace, Pid, gc_minor_end, Info}:
                  Sent when young garbage collection is  finished.  Info  con-
                  tains  the  same  kind of list as in message gc_minor_start,
                  but the sizes reflect the new sizes  after  garbage  collec-
                  tion.

                {trace, Pid, gc_major_start, Info}:
                  Sent  when  fullsweep  garbage  collection  is  about  to be
                  started. Info contains the same kind of list as  in  message
                  gc_minor_start.

                {trace, Pid, gc_major_end, Info}:
                  Sent  when  fullsweep  garbage  collection is finished. Info
                  contains the same kind of list as in message gc_minor_start,
                  but  the  sizes  reflect  the  new  sizes  after a fullsweep
                  garbage collection.

              If the tracing process/port dies or the  tracer  module  returns
              remove, the flags are silently removed.

              Each  process  can  only be traced by one tracer. Therefore, at-
              tempts to trace an already traced process fail.

              Returns a number indicating the number of processes that matched
              PidPortSpec.  If PidPortSpec is a process identifier, the return
              value is 1. If PidPortSpec is all or existing, the return  value
              is  the  number of processes running. If PidPortSpec is new, the
              return value is 0.

              Failure: badarg if the specified arguments  are  not  supported.
              For example, cpu_timestamp is not supported on all platforms.

       erlang:trace_delivered(Tracee) -> Ref

              Types:

                 Tracee = pid() | all
                 Ref = reference()

              The  delivery  of  trace  messages (generated by erlang:trace/3,
              seq_trace(3erl), or erlang:system_profile/2)  is  dislocated  on
              the  time-line  compared  to  other events in the system. If you
              know that Tracee has passed some specific point  in  its  execu-
              tion, and you want to know when at least all trace messages cor-
              responding to events up to this point have reached  the  tracer,
              use erlang:trace_delivered(Tracee).

              When  it  is guaranteed that all trace messages are delivered to
              the tracer up to the point that Tracee reached at  the  time  of
              the call to erlang:trace_delivered(Tracee), then a {trace_deliv-
              ered, Tracee,  Ref}  message  is  sent  to  the  caller  of  er-
              lang:trace_delivered(Tracee) .

              Notice  that  message  trace_delivered does not imply that trace
              messages have been delivered. Instead it implies that all  trace
              messages that are to be delivered have been delivered. It is not
              an error if Tracee is not, and has not been traced  by  someone,
              but  if  this is the case, no trace messages have been delivered
              when the trace_delivered message arrives.

              Notice that Tracee must refer to a process currently  or  previ-
              ously   existing   on  the  same  node  as  the  caller  of  er-
              lang:trace_delivered(Tracee) resides on. The special Tracee atom
              all denotes all processes that currently are traced in the node.

              When  used  together  with a  Tracer Module, any message sent in
              the trace callback is guaranteed to have reached  its  recipient
              before the trace_delivered message is sent.

              Example: Process A is Tracee, port B is tracer, and process C is
              the port owner of B. C wants to close B when A exits. To  ensure
              that  the trace is not truncated, C can call erlang:trace_deliv-
              ered(A) when A exits, and wait for message {trace_delivered,  A,
              Ref} before closing B.

              Failure:  badarg  if Tracee does not refer to a process (dead or
              alive) on the same node as  the  caller  of  erlang:trace_deliv-
              ered(Tracee) resides on.

       erlang:trace_info(PidPortFuncEvent, Item) -> Res

              Types:

                 PidPortFuncEvent =
                     pid() |
                     port() |
                     new | new_processes | new_ports |
                     {Module, Function, Arity} |
                     on_load | send | 'receive'
                 Module = module()
                 Function = atom()
                 Arity = arity()
                 Item =
                     flags | tracer | traced | match_spec | meta |
                     meta_match_spec | call_count | call_time | all
                 Res = trace_info_return()
                 trace_info_return() =
                     undefined |
                     {flags, [trace_info_flag()]} |
                     {tracer, pid() | port() | []} |
                     {tracer, module(), term()} |
                     trace_info_item_result() |
                     {all, [trace_info_item_result()] | false | undefined}
                 trace_info_item_result() =
                     {traced, global | local | false | undefined} |
                     {match_spec, trace_match_spec() | false | undefined} |
                     {meta, pid() | port() | false | undefined | []} |
                     {meta, module(), term()} |
                     {meta_match_spec, trace_match_spec() | false | undefined} |
                     {call_count, integer() >= 0 | boolean() | undefined} |
                     {call_time,
                      [{pid(),
                        integer() >= 0,
                        integer() >= 0,
                        integer() >= 0}] |
                      boolean() |
                      undefined}
                 trace_info_flag() =
                     send | 'receive' | set_on_spawn | call | return_to | procs |
                     set_on_first_spawn | set_on_link | running |
                     garbage_collection | timestamp | monotonic_timestamp |
                     strict_monotonic_timestamp | arity
                 trace_match_spec() =
                     [{[term()] | '_' | match_variable(), [term()], [term()]}]
                 match_variable() = atom()
                    Approximation of '$1' | '$2' | '$3' | ...

              Returns  trace  information  about a port, process, function, or
              event.

              To get information about a port or process, PidPortFuncEvent  is
              to be a process identifier (pid), port identifier, or one of the
              atoms new, new_processes, or new_ports. The atom new or new_pro-
              cesses  means  that  the default trace state for processes to be
              created is returned. The atom new_ports means that  the  default
              trace state for ports to be created is returned.

              Valid Items for ports and processes:

                flags:
                  Returns  a  list  of atoms indicating what kind of traces is
                  enabled for the process. The list is empty if no traces  are
                  enabled,  and  one or more of the followings atoms if traces
                  are enabled: send, 'receive', set_on_spawn, call, return_to,
                  procs, ports, set_on_first_spawn, set_on_link, running, run-
                  ning_procs, running_ports, silent, exiting,  monotonic_time-
                  stamp, strict_monotonic_timestamp, garbage_collection, time-
                  stamp, and arity. The order is arbitrary.

                tracer:
                  Returns the identifier for process, port, or  a  tuple  con-
                  taining  the  tracer  module  and  tracer state tracing this
                  process. If this process is not traced, the return value  is
                  [].

              To  get  information about a function, PidPortFuncEvent is to be
              the three-element tuple {Module, Function, Arity}  or  the  atom
              on_load.  No  wildcards  are  allowed.  Returns undefined if the
              function does not exist, or false if the function is not traced.
              If  PidPortFuncEvent is on_load, the information returned refers
              to the default value for code that will be loaded.

              Valid Items for functions:

                traced:
                  Returns global if this function is traced on global function
                  calls,  local  if  this function is traced on local function
                  calls (that is, local and global function calls), and  false
                  if local or global function calls are not traced.

                match_spec:
                  Returns the match specification for this function, if it has
                  one. If the function is locally or globally traced  but  has
                  no match specification defined, the returned value is [].

                meta:
                  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 false. If the function is
                  meta-traced but has once detected that the tracer process is
                  invalid, the returned value is [].

                meta_match_spec:
                  Returns  the  meta-trace  match specification for this func-
                  tion, if it has one. If the function is meta-traced but  has
                  no match specification defined, the returned value is [].

                call_count:
                  Returns  the  call count value for this function or true for
                  the pseudo function on_load if call count tracing is active.
                  Otherwise false is returned.

                  See also erlang:trace_pattern/3.

                call_time:
                  Returns  the  call time values for this function or true for
                  the pseudo function on_load if call time tracing is  active.
                  Otherwise  false is returned. The call time values returned,
                  [{Pid, Count, S, Us}], is a list of each process  that  exe-
                  cuted the function and its specific counters.

                  See also erlang:trace_pattern/3.

                all:
                  Returns  a  list containing the {Item, Value} tuples for all
                  other items, or returns false if no tracing  is  active  for
                  this function.

              To get information about an event, PidPortFuncEvent is to be one
              of the atoms send or 'receive'.

              One valid Item for events exists:

                match_spec:
                  Returns the match specification for this event,  if  it  has
                  one, or true if no match specification has been set.

              The  return value is {Item, Value}, where Value is the requested
              information as described earlier. If a pid for  a  dead  process
              was  specified, or the name of a non-existing function, Value is
              undefined.

       erlang:trace_pattern(MFA, MatchSpec) -> integer() >= 0

              Types:

                 MFA = trace_pattern_mfa() | send | 'receive'
                 MatchSpec =
                     (MatchSpecList :: trace_match_spec()) |
                     boolean() |
                     restart | pause
                 trace_pattern_mfa() = {atom(), atom(), arity() | '_'} | on_load
                 trace_match_spec() =
                     [{[term()] | '_' | match_variable(), [term()], [term()]}]
                 match_variable() = atom()
                    Approximation of '$1' | '$2' | '$3' | ...

              The same as erlang:trace_pattern(Event, MatchSpec, []), retained
              for backward compatibility.

       erlang:trace_pattern(MFA :: send, MatchSpec, FlagList :: []) ->
                               integer() >= 0

              Types:

                 MatchSpec = (MatchSpecList :: trace_match_spec()) | boolean()
                 trace_match_spec() =
                     [{[term()] | '_' | match_variable(), [term()], [term()]}]
                 match_variable() = atom()
                    Approximation of '$1' | '$2' | '$3' | ...

              Sets  trace  pattern  for message sending. Must be combined with
              erlang:trace/3 to set the send trace flag for one or  more  pro-
              cesses.  By default all messages sent from send traced processes
              are traced. To limit traced send events  based  on  the  message
              content,  the  sender and/or the receiver, use erlang:trace_pat-
              tern/3.

              Argument MatchSpec can take the following forms:

                MatchSpecList:
                  A list of match specifications. The matching is done on  the
                  list  [Receiver, Msg]. Receiver is the process or port iden-
                  tity of the receiver and Msg is the message term. The pid of
                  the  sending process can be accessed with the guard function
                  self/0. An empty list is the same as true. For more informa-
                  tion,  see  section   Match  Specifications in Erlang in the
                  User's Guide.

                true:
                  Enables tracing for all sent messages (from send traced pro-
                  cesses). Any match specification is removed. This is the de-
                  fault.

                false:
                  Disables tracing for all sent messages. Any match specifica-
                  tion is removed.

              Argument FlagList must be [] for send tracing.

              The return value is always 1.

              Examples:

              Only trace messages to a specific process Pid:

              > erlang:trace_pattern(send, [{[Pid, '_'],[],[]}], []).
              1

              Only trace messages matching {reply, _}:

              > erlang:trace_pattern(send, [{['_', {reply,'_'}],[],[]}], []).
              1

              Only trace messages sent to the sender itself:

              > erlang:trace_pattern(send, [{['$1', '_'],[{'=:=','$1',{self}}],[]}], []).
              1

              Only trace messages sent to other nodes:

              > erlang:trace_pattern(send, [{['$1', '_'],[{'=/=',{node,'$1'},{node}}],[]}], []).
              1

          Note:
              A  match specification for send trace can use all guard and body
              functions except caller.

              Fails by raising an error exception with an error reason of:

                badarg:
                  If an argument is invalid.

                system_limit:
                  If a match specification passed as  argument  has  excessive
                  nesting  which  causes  scheduler  stack  exhaustion for the
                  scheduler that the calling process is executing  on.  Sched-
                  uler  stack size can be configured when starting the runtime
                  system.

       erlang:trace_pattern(MFA :: 'receive', MatchSpec, FlagList :: []) ->
                               integer() >= 0

              Types:

                 MatchSpec = (MatchSpecList :: trace_match_spec()) | boolean()
                 trace_match_spec() =
                     [{[term()] | '_' | match_variable(), [term()], [term()]}]
                 match_variable() = atom()
                    Approximation of '$1' | '$2' | '$3' | ...

              Sets trace pattern for message receiving. Must be combined  with
              erlang:trace/3  to  set the 'receive' trace flag for one or more
              processes. By default all messages received by 'receive'  traced
              processes  are  traced.  To limit traced receive events based on
              the message content, the sender and/or  the  receiver,  use  er-
              lang:trace_pattern/3.

              Argument MatchSpec can take the following forms:

                MatchSpecList:
                  A  list of match specifications. The matching is done on the
                  list [Node, Sender, Msg]. Node  is  the  node  name  of  the
                  sender.  Sender  is  the  process  or  port  identity of the
                  sender, or the atom undefined if the  sender  is  not  known
                  (which  can be the case for remote senders). Msg is the mes-
                  sage term. The pid of the receiving process can be  accessed
                  with the guard function self/0. An empty list is the same as
                  true. For more information, see  section   Match  Specifica-
                  tions in Erlang in the User's Guide.

                true:
                  Enables  tracing  for  all  received  messages (to 'receive'
                  traced processes). Any match specification is removed.  This
                  is the default.

                false:
                  Disables tracing for all received messages. Any match speci-
                  fication is removed.

              Argument FlagList must be [] for receive tracing.

              The return value is always 1.

              Examples:

              Only trace messages from a specific process Pid:

              > erlang:trace_pattern('receive', [{['_',Pid, '_'],[],[]}], []).
              1

              Only trace messages matching {reply, _}:

              > erlang:trace_pattern('receive', [{['_','_', {reply,'_'}],[],[]}], []).
              1

              Only trace messages from other nodes:

              > erlang:trace_pattern('receive', [{['$1', '_', '_'],[{'=/=','$1',{node}}],[]}], []).
              1

          Note:
              A match specification for 'receive' trace can use all guard  and
              body   functions  except  caller,  is_seq_trace,  get_seq_token,
              set_seq_token, enable_trace, disable_trace, trace,  silent,  and
              process_dump.

              Fails by raising an error exception with an error reason of:

                badarg:
                  If an argument is invalid.

                system_limit:
                  If  a  match  specification passed as argument has excessive
                  nesting which causes  scheduler  stack  exhaustion  for  the
                  scheduler  that  the calling process is executing on. Sched-
                  uler stack size can be configured when starting the  runtime
                  system.

       erlang:trace_pattern(MFA, MatchSpec, FlagList) ->
                               integer() >= 0

              Types:

                 MFA = trace_pattern_mfa()
                 MatchSpec =
                     (MatchSpecList :: trace_match_spec()) |
                     boolean() |
                     restart | pause
                 FlagList = [trace_pattern_flag()]
                 trace_pattern_mfa() = {atom(), atom(), arity() | '_'} | on_load
                 trace_match_spec() =
                     [{[term()] | '_' | match_variable(), [term()], [term()]}]
                 trace_pattern_flag() =
                     global | local | meta |
                     {meta, Pid :: pid()} |
                     {meta, TracerModule :: module(), TracerState :: term()} |
                     call_count | call_time
                 match_variable() = atom()
                    Approximation of '$1' | '$2' | '$3' | ...

              Enables or disables call tracing for one or more functions. Must
              be combined with erlang:trace/3 to set the call trace  flag  for
              one or more processes.

              Conceptually,  call  tracing works as follows. Inside 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.

              To add or remove one or more processes to the set of traced pro-
              cesses, use erlang:trace/3.

              To  add  or remove functions to the set of traced functions, use
              erlang:trace_pattern/3.

              The BIF erlang:trace_pattern/3 can also add match specifications
              to  a  function.  A match specification comprises a pattern that
              the function arguments must match, a guard expression that  must
              evaluate to true, and an action to be performed. The default ac-
              tion is to send a trace message. If the pattern does  not  match
              or the guard fails, the action is not executed.

              Argument  MFA  is  to be a tuple, such as {Module, Function, Ar-
              ity}, or the atom on_load (described below). It can be the  mod-
              ule,  function,  and  arity for a function (or a BIF in any mod-
              ule). The atom '_' can be used as a wildcard in any of the  fol-
              lowing ways:

                {Module,Function,'_'}:
                  All functions of any arity named Function in module Module.

                {Module,'_','_'}:
                  All functions in module Module.

                {'_','_','_'}:
                  All functions in all loaded modules.

              Other combinations, such as {Module,'_',Arity}, are not allowed.
              Local functions match wildcards  only  if  option  local  is  in
              FlagList.

              If argument MFA is the atom on_load, the match specification and
              flag list are used on all modules that are newly loaded.

              Argument MatchSpec can take the following forms:

                false:
                  Disables tracing for the matching functions. Any match spec-
                  ification is removed.

                true:
                  Enables tracing for the matching functions. Any match speci-
                  fication is removed.

                MatchSpecList:
                  A list of match specifications. An empty list is  equivalent
                  to true. For a description of match specifications, see sec-
                  tion  Match Specifications in Erlang in the User's Guide.

                restart:
                  For the FlagList options call_count and call_time:  restarts
                  the  existing  counters. The behavior is undefined for other
                  FlagList options.

                pause:
                  For the FlagList options call_count  and  call_time:  pauses
                  the  existing  counters. The behavior is undefined for other
                  FlagList options.

              Parameter FlagList is a list of options. The following  are  the
              valid options:

                global:
                  Turns on or off call tracing for global function calls (that
                  is, calls specifying the module explicitly).  Only  exported
                  functions  match  and  only global calls generate trace mes-
                  sages. This is the default.

                local:
                  Turns on or off call  tracing  for  all  types  of  function
                  calls. Trace messages are sent whenever any of the specified
                  functions are called, regardless of how they are called.  If
                  flag  return_to  is set for the process, a return_to message
                  is also sent when this function returns to its caller.

                meta | {meta, Pid} | {meta, TracerModule, TracerState}:
                  Turns on or off  meta-tracing  for  all  types  of  function
                  calls. Trace messages are sent to the tracer whenever any of
                  the specified functions are called. If no tracer  is  speci-
                  fied, self() is used as a default tracer process.

                  Meta-tracing  traces  all  processes and does not care about
                  the process trace flags set  by  erlang:trace/3,  the  trace
                  flags are instead fixed to [call, timestamp].

                  The  match  specification function {return_trace} works with
                  meta-trace and sends its trace message to the same tracer.

                call_count:
                  Starts (MatchSpec == true) or  stops  (MatchSpec  ==  false)
                  call  count tracing for all types of function calls. For ev-
                  ery function, a counter is incremented when the function  is
                  called,  in  any  process. No process trace flags need to be
                  activated.

                  If call count tracing is started while already running,  the
                  count is restarted from zero. To pause running counters, use
                  MatchSpec == pause.  Paused  and  running  counters  can  be
                  restarted from zero with MatchSpec == restart.

                  To read the counter value, use erlang:trace_info/2.

                call_time:
                  Starts  (MatchSpec  ==  true)  or stops (MatchSpec == false)
                  call time tracing for all types of function calls. For every
                  function,  a  counter  is  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.

                  If call time tracing is started while already  running,  the
                  count and time restart from zero. To pause running counters,
                  use MatchSpec == pause. Paused and running counters  can  be
                  restarted from zero with MatchSpec == restart.

                  To read the counter value, use erlang:trace_info/2.

              The  options global and local are mutually exclusive, and global
              is the default  (if  no  options  are  specified).  The  options
              call_count  and meta perform a kind of local tracing, and cannot
              be combined with global. A function can be globally  or  locally
              traced.  If  global tracing is specified for a set of functions,
              then local, meta, call time, and  call  count  tracing  for  the
              matching set of local functions is disabled, and conversely.

              When  disabling  trace,  the option must match the type of trace
              set on the function. That is, local  tracing  must  be  disabled
              with  option  local and global tracing with option global (or no
              option), and so on.

              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  erlang:trace_info/2 to retrieve the existing match specifi-
              cation.

              Returns the number of functions matching argument MFA.  This  is
              zero if none matched.

              Fails by raising an error exception with an error reason of:

                badarg:
                  If an argument is invalid.

                system_limit:
                  If  a  match  specification passed as argument has excessive
                  nesting which causes  scheduler  stack  exhaustion  for  the
                  scheduler  that  the calling process is executing on. Sched-
                  uler stack size can be configured when starting the  runtime
                  system.

       trunc(Number) -> integer()

              Types:

                 Number = number()

              Returns an integer by truncating Number, for example:

              > trunc(5.5).
              5

              Allowed in guard tests.

       tuple_size(Tuple) -> integer() >= 0

              Types:

                 Tuple = tuple()

              Returns  an integer that is the number of elements in Tuple, for
              example:

              > tuple_size({morni, mulle, bwange}).
              3

              Allowed in guard tests.

       tuple_to_list(Tuple) -> [term()]

              Types:

                 Tuple = tuple()

              Returns a list corresponding to Tuple. Tuple can contain any Er-
              lang terms. Example:

              > tuple_to_list({share, {'Ericsson_B', 163}}).
              [share,{'Ericsson_B',163}]

       erlang:unique_integer() -> integer()

              Generates and returns an  integer unique on current runtime sys-
              tem instance. The same as calling erlang:unique_integer([]).

       erlang:unique_integer(ModifierList) -> integer()

              Types:

                 ModifierList = [Modifier]
                 Modifier = positive | monotonic

              Generates and returns an  integer unique on current runtime sys-
              tem  instance. The integer is unique in the sense that this BIF,
              using the same set of modifiers, does not return the same  inte-
              ger  more than once on the current runtime system instance. Each
              integer value can of course be constructed by other means.

              By default, when [] is passed as ModifierList, both negative and
              positive  integers can be returned. This to use the range of in-
              tegers that do not need heap memory allocation as much as possi-
              ble.  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.

              Modifiers:

                positive:
                  Returns only positive integers.

                  Notice  that  by  passing the positive modifier you will get
                  heap allocated integers (bignums) quicker.

                monotonic:
                  Returns  strictly monotonically increasing  integers  corre-
                  sponding  to creation time. That is, the integer returned is
                  always larger than previously returned integers on the  cur-
                  rent runtime system instance.

                  These  values  can be used to determine order between events
                  on the runtime system instance. That is, if  both  X  =  er-
                  lang:unique_integer([monotonic]) and Y = erlang:unique_inte-
                  ger([monotonic]) are executed by different processes (or the
                  same process) on the same runtime system instance and X < Y,
                  we know that X was created before Y.

            Warning:
                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  monotonic  modifier  unless  you  really  need
                strictly monotonically increasing values.

              All valid Modifiers can be combined. Repeated (valid)  Modifiers
              in the ModifierList are ignored.

          Note:
              The  set  of  integers returned by erlang:unique_integer/1 using
              different sets of Modifiers will overlap. For example, by  call-
              ing  unique_integer([monotonic]),  and unique_integer([positive,
              monotonic]) repeatedly, you will eventually  see  some  integers
              that are returned by both calls.

              Failures:

                badarg:
                  if ModifierList is not a proper list.

                badarg:
                  if Modifier is not a valid modifier.

       erlang:universaltime() -> DateTime

              Types:

                 DateTime = calendar:datetime()

              Returns  the  current  date and time according to Universal Time
              Coordinated (UTC)  in  the  form  {{Year,  Month,  Day},  {Hour,
              Minute,  Second}}  if  supported by the underlying OS. Otherwise
              erlang:universaltime() is equivalent to erlang:localtime().  Ex-
              ample:

              > erlang:universaltime().
              {{1996,11,6},{14,18,43}}

       erlang:universaltime_to_localtime(Universaltime) -> Localtime

              Types:

                 Localtime = Universaltime = calendar:datetime()

              Converts Universal Time Coordinated (UTC) date and time to local
              date and time in the form {{Year, Month,  Day},  {Hour,  Minute,
              Second}} if supported by the underlying OS. Otherwise no conver-
              sion is done, and Universaltime is returned. Example:

              > erlang:universaltime_to_localtime({{1996,11,6},{14,18,43}}).
              {{1996,11,7},{15,18,43}}

              Failure: badarg if Universaltime denotes  an  invalid  date  and
              time.

       unlink(Id) -> true

              Types:

                 Id = pid() | port()

              Removes  the  link, if there is one, between the calling process
              and the process or port referred to by Id.

              Returns true and does not fail, even if there is no link to  Id,
              or if Id does not exist.

              Once unlink(Id) has returned, it is guaranteed that the link be-
              tween the caller and the entity referred to by Id has no  effect
              on the caller in the future (unless the link is setup again). If
              the caller is trapping exits, an {'EXIT', Id,  _}  message  from
              the  link can have been placed in the caller's message queue be-
              fore the call.

              Notice that the {'EXIT', Id, _} message can be the result of the
              link,  but  can  also be the result of Id calling exit/2. There-
              fore, it can be appropriate to clean up the message  queue  when
              trapping exits after the call to unlink(Id), as follows:

              unlink(Id),
              receive
                  {'EXIT', Id, _} ->
                      true
              after 0 ->
                      true
              end

          Note:
              Before  Erlang/OTP  R11B  (ERTS 5.5) unlink/1 behaved completely
              asynchronously, that is, the link was active until  the  "unlink
              signal"  reached  the linked entity. This had an undesirable ef-
              fect, as you could never know when you were guaranteed not to be
              effected by the link.

              The  current  behavior can be viewed as two combined operations:
              asynchronously send an "unlink signal" to the linked entity  and
              ignore any future results of the link.

       unregister(RegName) -> true

              Types:

                 RegName = atom()

              Removes  the  registered  name RegName associated with a process
              identifier or a port identifier, for example:

              > unregister(db).
              true

              Users are advised not to unregister system processes.

              Failure: badarg if RegName is not a registered name.

       whereis(RegName) -> pid() | port() | undefined

              Types:

                 RegName = atom()

              Returns the process identifier or port identifier with the  reg-
              istered  name RegName. Returns undefined if the name is not reg-
              istered. Example:

              > whereis(db).
              <0.43.0>

       erlang:yield() -> true

              Voluntarily lets other processes (if any) get a chance  to  exe-
              cute.  Using  this  function is similar to receive after 1 -> ok
              end, except that yield() is faster.

          Warning:
              There is seldom or never any need to use this BIF as other  pro-
              cesses  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.

Ericsson AB                       erts 11.0.2                     erlang(3erl)

Man(1) output converted with man2html
list of all man pages