【Erlang新手成长日记】erl手册

erl(1)                           User Commands                          erl(1)

NAME
       erl - The Erlang Emulator

DESCRIPTION
       The erl program starts an Erlang runtime system. The exact details (for
       example, whether erl is a script or a program and which other  programs
       it calls) are system-dependent.

       Windows  users  probably  wants  to use the werl program instead, which
       runs in its own window with scrollbars and supports command-line  edit‐
       ing.  The erl program on Windows provides no line editing in its shell,
       and on Windows 95 there is no way to scroll  back  to  text  which  has
       scrolled  off  the  screen.  The  erl program must be used, however, in
       pipelines or if you want to redirect standard input or output.

   Note:
       As of ERTS version 5.8 (OTP-R14A) the runtime system  will  by  default
       bind  schedulers（调度程序） to logical processors using the default_bind bind type
       if the amount of schedulers are at least equal to the amount of logical
       processors  configured,  binding  of schedulers is supported, and a CPU
       topology is available at startup.

       If the Erlang runtime system is the only operating system process  that
       binds  threads  to logical processors, this improves the performance of
       the runtime system. However, if other operating  system  processes  (as
       for example another Erlang runtime system) also bind threads to logical
       processors, there might be a performance penalty（性能损失） instead.  If  this  is
       the  case you, are are advised to unbind the schedulers using the +sbtu
       command  line  argument,  or  by   invoking   erlang:system_flag(sched‐
       uler_bind_type, unbound).


EXPORTS
       erl <arguments>

              Starts an Erlang runtime system.

              The  arguments  can  be  divided  into emulator flags, flags and
              plain arguments:

                * Any argument starting with the character + is interpreted as
                  an emulator flag.

                  As indicated by the name, emulator flags controls the behav‐
                  ior of the emulator.


                * Any argument starting  with  the  character  -  (hyphen)  is
                  interpreted  as  a flag which should be passed to the Erlang
                  part of the runtime system, more specifically  to  the  init
                  system process, see init(3erl).

                  The  init process itself interprets some of these flags, the
                  init flags. It also stores any  remaining  flags,  the  user
                  flags. The latter can be retrieved by calling init:get_argu‐
                  ment/1.


                  It can be noted that there are a small number of  "-"  flags
                  which  now  actually are emulator flags, see the description
                  below.


                * Plain arguments are not interpreted in  any  way.  They  are
                  also  stored  by  the  init  process and can be retrieved by
                  calling  init:get_plain_arguments/0.  Plain  arguments   can
                  occur  before  the first flag, or after a -- flag. Addition‐
                  ally, the flag -extra  causes  everything  that  follows  to
                  become plain arguments.

              Example:

              % erl +W w -sname arnie +R 9 -s my_init -extra +bertie
              (arnie@host)1> init:get_argument(sname).
              {ok,[["arnie"]]}
              (arnie@host)2> init:get_plain_arguments().
              ["+bertie"]

              Here  +W  w  and  +R 9 are emulator flags. -s my_init is an init
              flag, interpreted by init. -sname arnie is a user  flag,  stored
              by  init. It is read by Kernel and will cause the Erlang runtime
              system to become distributed. Finally, everything  after  -extra
              (that is, +bertie) is considered as plain arguments.

              % erl -myflag 1
              1> init:get_argument(myflag).
              {ok,[["1"]]}
              2> init:get_plain_arguments().
              []

              Here the user flag -myflag 1 is passed to and stored by the init
              process. It is a user defined flag, presumably（大概） used by some user
              defined application.


FLAGS
       In the following list, init flags are marked (init flag). Unless other‐
       wise specified, all other flags are user flags, for  which  the  values
       can  be retrieved by calling init:get_argument/1. Note that the list of
       user flags is not exhaustive（全面的）, there may be additional, application spe‐
       cific  flags which instead are documented in the corresponding applica‐
       tion documentation.

         --(init flag):
           Everything following -- up to the next flag  (-flag  or  +flag)  is
           considered   plain   arguments   and   can   be   retrieved   using
           init:get_plain_arguments/0.

         -Application Par Val:
           Sets the application configuration parameter Par to the  value  Val
           for the application Application, see app(5) and application(3erl).

         -args_file FileName:
           Command  line  arguments are read from the file FileName. The argu‐
           ments read from the file replace the '-args_file FileName' flag  on
           the resulting command line.

           The  file FileName should be a plain text file and may contain com‐
           ments and command line arguments. A comment begins with a # charac‐
           ter  and continues until next end of line character. Backslash (\\)
           is used as quoting character. All command line  arguments  accepted
           by  erl  are allowed, also the -args_file FileName flag. Be careful
           not to cause circular dependencies  between  files  containing  the
           -args_file flag, though.


           The  -extra flag is treated specially. Its scope ends at the end of
           the file. Arguments following an -extra flag are moved on the  com‐
           mand line into the -extra section, i.e. the end of the command line
           following after an -extra flag.


         -async_shell_start:
           The initial Erlang shell does not read user input until the  system
           boot procedure has been completed (Erlang 5.4 and later). This flag
           disables the start synchronization feature and lets the shell start
           in parallel with the rest of the system.

         -boot File:
           Specifies  the  name  of the boot file, File.boot, which is used to
           start the system. See init(3erl). Unless File contains an  absolute
           path,  the  system  searches  for  File.boot  in  the  current  and
           $ROOT/bin directories.

           Defaults to $ROOT/bin/start.boot.


         -boot_var Var Dir:
           If the boot script contains a path variable Var other  than  $ROOT,
           this  variable  is  expanded  to  Dir.  Used  when applications are
           installed  in  another   directory   than   $ROOT/lib,   see   sys‐
           tools:make_script/1,2.

         -code_path_cache:
           Enables the code path cache of the code server, see code(3erl).

         -compile Mod1 Mod2 ...:
           Compiles  the  specified modules and then terminates (with non-zero
           exit code if the compilation of some file did not succeed). Implies
           -noinput. Not recommended - use erlc instead.

         -config Config:
           Specifies the name of a configuration file, Config.config, which is
           used to configure applications. See app(5) and application(3erl).

         -connect_all false:
           If this flag is present, global will not maintain a fully connected
           network of distributed Erlang nodes, and then global name registra‐
           tion cannot be used. See global(3erl).

         -cookie Cookie:
           Obsolete flag without any effect and common misspelling  for  -set‐
           cookie. Use -setcookie instead.

         -detached:
           Starts  the Erlang runtime system detached from the system console.
           Useful for  running  daemons  and  backgrounds  processes.  Implies
           -noinput.

         -emu_args:
           Useful  for  debugging. Prints out the actual arguments sent to the
           emulator.

         -env Variable Value:
           Sets the host OS environment variable Variable to the  value  Value
           for the Erlang runtime system. Example:

         % erl -env DISPLAY gin:0

           In  this example, an Erlang runtime system is started with the DIS‐
           PLAY environment variable set to gin:0.


         -eval Expr(init flag):
           Makes init evaluate the expression Expr, see init(3erl).

         -extra(init flag):
           Everything following -extra is considered plain arguments  and  can
           be retrieved using init:get_plain_arguments/0.

         -heart:
           Starts  heart  beat  monitoring  of  the Erlang runtime system. See
           heart(3erl).

         -hidden:
           Starts the Erlang runtime system as a hidden node, if it is run  as
           a  distributed  node.  Hidden nodes always establish hidden connec‐
           tions to all other nodes except for nodes in the same global group.
           Hidden  connections  are  not  published on either of the connected
           nodes, i.e. neither of the connected nodes are part of  the  result
           from  nodes/0  on  the  other  node. See also hidden global groups,
           global_group(3erl).

         -hosts Hosts:
           Specifies the IP addresses for  the  hosts  on  which  Erlang  boot
           servers are running, see erl_boot_server(3erl). This flag is manda‐
           tory if the -loader inet flag is present.

           The IP addresses must be given in the standard form  (four  decimal
           numbers  separated  by  periods, for example "150.236.20.74". Hosts
           names are not acceptable, but a broadcast address (preferably  lim‐
           ited to the local network) is.


         -id Id:
           Specifies  the  identity of the Erlang runtime system. If it is run
           as a distributed node, Id must be identical to  the  name  supplied
           together with the -sname or -name flag.

         -init_debug:
           Makes init write some debug information while interpreting the boot
           script.

         -instr(emulator flag):
           Selects an instrumented Erlang runtime system (virtual machine)  to
           run, instead of the ordinary one. When running an instrumented run‐
           time system, some resource usage data can be obtained and  analysed
           using  the module instrument. Functionally, it behaves exactly like
           an ordinary Erlang runtime system.

         -loader Loader:
           Specifies the method used by erl_prim_loader to load Erlang modules
           into  the system. See erl_prim_loader(3erl). Two Loader methods are
           supported, efile and inet. efile means use the local  file  system,
           this  is  the  default.  inet  means  use  a boot server on another
           machine, and the -id, -hosts and -setcookie flags must be specified
           as well. If Loader is something else, the user supplied Loader port
           program is started.

         -make:
           Makes the Erlang runtime system invoke make:all()  in  the  current
           working  directory  and  then  terminate.  See  make(3erl). Implies
           -noinput.

         -man Module:
           Displays the manual page for the Erlang module  Module.  Only  sup‐
           ported on Unix.

         -mode interactive | embedded:
           Indicates if the system should load code dynamically (interactive),
           or if all  code  should  be  loaded  during  system  initialization
           (embedded), see code(3erl). Defaults to interactive.

         -name Name:
           Makes  the Erlang runtime system into a distributed node. This flag
           invokes all network servers necessary for a node to become distrib‐
           uted.  See  net_kernel(3erl).  It is also ensured that epmd runs on
           the current host before Erlang is started. See epmd(1).

           The name of the node will be Name@Host, where  Host  is  the  fully
           qualified  host  name of the current host. For short names, use the
           -sname flag instead.


         -noinput:
           Ensures that the Erlang runtime system  never  tries  to  read  any
           input. Implies -noshell.

         -noshell:
           Starts  an  Erlang runtime system with no shell. This flag makes it
           possible to have the Erlang runtime system  as  a  component  in  a
           series of UNIX pipes.

         -nostick:
           Disables  the  sticky directory facility of the Erlang code server,
           see code(3erl).

         -oldshell:
           Invokes the old Erlang shell from Erlang 3.3.  The  old  shell  can
           still be used.

         -pa Dir1 Dir2 ...:
           Adds  the  specified directories to the beginning of the code path,
           similar to code:add_pathsa/1. See code(3erl). As an alternative  to
           -pa, if several directories are to be prepended to the code and the
           directories have a common parent directory, that  parent  directory
           could  be  specified  in  the  ERL_LIBS  environment  variable. See
           code(3erl).

         -pz Dir1 Dir2 ...:
           Adds the specified directories to the end of the code path, similar
           to code:add_pathsz/1. See code(3erl).

         -remsh Node:
           Starts Erlang with a remote shell connected to Node.

         -rsh Program:
           Specifies  an  alternative  to  rsh  for starting a slave node on a
           remote host. See slave(3erl).

         -run Mod [Func [Arg1, Arg2, ...]](init flag):
           Makes init call the specified function. Func defaults to start.  If
           no  arguments  are provided, the function is assumed to be of arity
           0. Otherwise it is assumed to  be  of  arity  1,  taking  the  list
           [Arg1,Arg2,...]  as  argument. All arguments are passed as strings.
           See init(3erl).

         -s Mod [Func [Arg1, Arg2, ...]](init flag):
           Makes init call the specified function. Func defaults to start.  If
           no  arguments  are provided, the function is assumed to be of arity
           0. Otherwise it is assumed to  be  of  arity  1,  taking  the  list
           [Arg1,Arg2,...] as argument. All arguments are passed as atoms. See
           init(3erl).

         -setcookie Cookie:
           Sets   the   magic   cookie   of   the   node   to   Cookie,    see
           erlang:set_cookie/2.

         -shutdown_time Time:
           Specifies  how  long  time  (in  milliseconds)  the init process is
           allowed to spend shutting down the system. If Time ms have elapsed,
           all processes still existing are killed. Defaults to infinity.

         -sname Name:
           Makes the Erlang runtime system into a distributed node, similar to
           -name, but the host name portion of the node name Name@Host will be
           the short name, not fully qualified.

           This is sometimes the only way to run distributed Erlang if the DNS
           (Domain Name System) is not running. There can be no  communication
           between  nodes  running with the -sname flag and those running with
           the -name flag, as node names must be unique in distributed  Erlang
           systems.


         -smp [enable|auto|disable]:
           -smp enable and -smp starts the Erlang runtime system with SMP sup‐
           port enabled. This may fail if no runtime system with  SMP  support
           is  available.  -smp auto starts the Erlang runtime system with SMP
           support enabled if it is available and more than one  logical  pro‐
           cessor  are  detected. -smp disable starts a runtime system without
           SMP support. By default -smp auto will be used unless a conflicting
           parameter  has  been  passed,  then -smp disable will be used. Cur‐
           rently only the -hybrid parameter conflicts with -smp auto.

           NOTE: The runtime system with SMP support will not be available  on
           all supported platforms. See also the +S flag.


         -version(emulator flag):
           Makes  the  emulator  print out its version number. The same as erl
           +V.

EMULATOR FLAGS
       erl invokes the code for the Erlang emulator (virtual  machine),  which
       supports the following flags:

         +a size:
           Suggested stack size, in kilowords, for threads in the async-thread
           pool. Valid range is 16-8192 kilowords. The default suggested stack
           size  is  16  kilowords,  i.e, 64 kilobyte on 32-bit architectures.
           This small default size has been chosen since the amount of  async-
           threads  might be quite large. The default size is enough for driv‐
           ers delivered with Erlang/OTP, but might not be sufficiently  large
           for other dynamically linked in drivers that use the driver_async()
           functionality. Note that the value passed is only a suggestion, and
           it might even be ignored on some platforms.

         +A size:
           Sets  the  number  of  threads in async thread pool, valid range is
           0-1024. Default is 0.

         +B [c | d | i]:
           The c option makes Ctrl-C interrupt the current  shell  instead  of
           invoking the emulator break handler. The d option (same as specify‐
           ing +B without an extra option) disables the break handler.  The  i
           option makes the emulator ignore any break signal.

           If  the c option is used with oldshell on Unix, Ctrl-C will restart
           the shell process rather than interrupt it.


           Note that on Windows, this flag is only applicable  for  werl,  not
           erl (oldshell). Note also that Ctrl-Break is used instead of Ctrl-C
           on Windows.


         +c:
           Disable compensation for sudden changes of system time.

           Normally, erlang:now/0 will not immediately reflect sudden  changes
           in  the  system  time,  in order to keep timers (including receive-
           after) working. Instead, the time  maintained  by  erlang:now/0  is
           slowly  adjusted  towards the new system time. (Slowly means in one
           percent adjustments; if the time is off by  one  minute,  the  time
           will be adjusted in 100 minutes.)


           When  the  +c  option  is given, this slow adjustment will not take
           place. Instead erlang:now/0 will always reflect the current  system
           time.  Note  that  timers  are based on erlang:now/0. If the system
           time jumps, timers then time out at the wrong time.


         +d:
           If the emulator detects an internal error (or runs out of  memory),
           it  will by default generate both a crash dump and a core dump. The
           core dump will, however, not be very useful since  the  content  of
           process heaps is destroyed by the crash dump generation.

           The  +d  option  instructs the emulator to only produce a core dump
           and no crash dump if an internal error is detected.


           Calling erlang:halt/1 with a string argument will still  produce  a
           crash dump.


         +e Number:
           Set max number of ETS tables.

         +ec:
           Force  the  compressed  option on all ETS tables. Only intended for
           test and evaluation.

         +fnl:
           The VM works with file names as if they are encoded using the  ISO-
           latin-1  encoding,  disallowing  Unicode characters with codepoints
           beyond 255. This is default on operating systems that  have  trans‐
           parent file naming, i.e. all Unixes except MacOSX.

         +fnu:
           The VM works with file names as if they are encoded using UTF-8 (or
           some other system specific Unicode encoding). This is  the  default
           on  operating  systems  that enforce Unicode encoding, i.e. Windows
           and MacOSX.

           By enabling Unicode file name translation on systems where this  is
           not  default,  you  open up to the possibility that some file names
           can not be interpreted by the VM and therefore will be returned  to
           the  program  as  raw  binaries. The option is therefore considered
           experimental.


         +fna:
           Selection between +fnl and +fnu is done based on the current locale
           settings  in the OS, meaning that if you have set your terminal for
           UTF-8 encoding, the filesystem is expected to use the same encoding
           for filenames (use with care).

         +hms Size:
           Sets the default heap size of processes to the size Size.

         +hmbs Size:
           Sets  the default binary virtual heap size of processes to the size
           Size.

         +K true | false:
           Enables or disables the kernel poll functionality if  the  emulator
           supports  it. Default is false (disabled). If the emulator does not
           support kernel poll, and the +K flag is passed to the  emulator,  a
           warning is issued at startup.

         +l:
           Enables auto load tracing, displaying info while loading code.

         +MFlag Value:
           Memory  allocator  specific flags, see erts_alloc(3erl) for further
           information.

         +P Number:
           Sets the maximum number of concurrent processes  for  this  system.
           Number must be in the range 16..134217727. Default is 32768.

         +R ReleaseNumber:
           Sets the compatibility mode.

           The  distribution mechanism is not backwards compatible by default.
           This flags sets the emulator in compatibility mode with an  earlier
           Erlang/OTP release ReleaseNumber. The release number must be in the
           range 7..<current release>. This limits  the  emulator,  making  it
           possible for it to communicate with Erlang nodes (as well as C- and
           Java nodes) running that earlier release.


           For example, an R10 node is not automatically compatible with an R9
           node, but R10 nodes started with the +R 9 flag can co-exist with R9
           nodes in the same distributed Erlang system, they  are  R9-compati‐
           ble.


           Note:  Make  sure all nodes (Erlang-, C-, and Java nodes) of a dis‐
           tributed Erlang system is of the same Erlang/OTP release,  or  from
           two  different  Erlang/OTP releases X and Y, where all Y nodes have
           compatibility mode X.


           For example: A distributed Erlang system can consist of R10  nodes,
           or  of  R9  nodes and R9-compatible R10 nodes, but not of R9 nodes,
           R9-compatible R10 nodes and "regular" R10 nodes, as R9  and  "regu‐
           lar" R10 nodes are not compatible.


         +r:
           Force ets memory block to be moved on realloc.

         +rg ReaderGroupsLimit:
           Limits  the  amount of reader groups used by read/write locks opti‐
           mized for read operations in the Erlang runtime system. By  default
           the reader groups limit equals 8.

           When  the  amount of schedulers is less than or equal to the reader
           groups limit, each scheduler has its own  reader  group.  When  the
           amount of schedulers is larger than the reader groups limit, sched‐
           ulers share reader groups. Shared reader groups degrades read  lock
           and  read  unlock performance while a large amount of reader groups
           degrades write lock performance, so the limit is a tradeoff between
           performance  for  read  operations and performance for write opera‐
           tions. Each  reader  group  currently  consumes  64  byte  in  each
           read/write  lock.  Also  note  that  a  runtime system using shared
           reader groups benefits from binding schedulers to  logical  proces‐
           sors, since the reader groups are distributed better between sched‐
           ulers.


         +S Schedulers:SchedulerOnline:
           Sets the amount  of  scheduler  threads  to  create  and  scheduler
           threads  to  set  online  when  SMP support has been enabled. Valid
           range for both values are 1-1024. If the Erlang runtime  system  is
           able  to  determine the amount of logical processors configured and
           logical processors available, Schedulers will  default  to  logical
           processors configured, and SchedulersOnline will default to logical
           processors available; otherwise, the  default  values  will  be  1.
           Schedulers  may  be  omitted  if  :SchedulerOnline  is not and vice
           versa. The amount of schedulers online can be changed at  run  time
           via erlang:system_flag(schedulers_online, SchedulersOnline).

           This  flag will be ignored if the emulator doesn't have SMP support
           enabled (see the -smp flag).


         +sFlag Value:
           Scheduling specific flags.

           +sbt BindType:
             Set scheduler bind type. Currently valid BindTypes:

             u:
               Same as erlang:system_flag(scheduler_bind_type, unbound).

             ns:
               Same as erlang:system_flag(scheduler_bind_type, no_spread).

             ts:
               Same as erlang:system_flag(scheduler_bind_type, thread_spread).

             ps:
               Same   as    erlang:system_flag(scheduler_bind_type,    proces‐
               sor_spread).

             s:
               Same as erlang:system_flag(scheduler_bind_type, spread).

             nnts:
               Same         as         erlang:system_flag(scheduler_bind_type,
               no_node_thread_spread).

             nnps:
               Same as erlang:system_flag(scheduler_bind_type, no_node_proces‐
               sor_spread).

             tnnps:
               Same         as         erlang:system_flag(scheduler_bind_type,
               thread_no_node_processor_spread).

             db:
               Same as erlang:system_flag(scheduler_bind_type, default_bind).

             Binding of schedulers is currently only supported on newer Linux,
             Solaris, FreeBSD, and Windows systems.


             If  no  CPU topology is available when the +sbt flag is processed
             and BindType is any other type than u, the  runtime  system  will
             fail  to  start. CPU topology can be defined using the +sct flag.
             Note that the +sct flag may have to be  passed  before  the  +sbt
             flag  on the command line (in case no CPU topology has been auto‐
             matically detected).


             The runtime system will by default  bind  schedulers  to  logical
             processors  using  the  default_bind  bind  type if the amount of
             schedulers are at least equal to the amount of logical processors
             configured,  binding of schedulers is supported, and a CPU topol‐
             ogy is available at startup.


             NOTE: If the Erlang runtime system is the only  operating  system
             process  that  binds threads to logical processors, this improves
             the performance of the runtime system. However, if other  operat‐
             ing  system processes (as for example another Erlang runtime sys‐
             tem) also bind threads to logical processors, there  might  be  a
             performance penalty instead. If this is the case you, are advised
             to unbind the schedulers using the +sbtu command  line  argument,
             or by invoking erlang:system_flag(scheduler_bind_type, unbound).


             For more information, see erlang:system_flag(scheduler_bind_type,
             SchedulerBindType).


           +sct CpuTopology:


             * <Id> = integer(); when 0 =< <Id> =< 65535

             * <IdRange> = <Id>-<Id>

             * <IdOrIdRange> = <Id> | <IdRange>

             * <IdList> = <IdOrIdRange>,<IdOrIdRange> | <IdOrIdRange>

             * <LogicalIds> = L<IdList>

             * <ThreadIds> = T<IdList> | t<IdList>

             * <CoreIds> = C<IdList> | c<IdList>

             * <ProcessorIds> = P<IdList> | p<IdList>

             * <NodeIds> = N<IdList> | n<IdList>

             * <IdDefs>       =       <LogicalIds><ThreadIds><CoreIds><Proces‐
               sorIds><NodeIds>         |         <LogicalIds><ThreadIds><Cor‐
               eIds><NodeIds><ProcessorIds>

             * CpuTopology = <IdDefs>:<IdDefs> | <IdDefs>

             Upper-case letters signify real identifiers and  lower-case  let‐
             ters  signify  fake  identifiers only used for description of the
             topology. Identifiers passed as real identifiers may be  used  by
             the runtime system when trying to access specific hardware and if
             they are not correct the behavior is undefined. Faked logical CPU
             identifiers  are not accepted since there is no point in defining
             the CPU topology without real logical  CPU  identifiers.  Thread,
             core,  processor,  and  node identifiers may be left out. If left
             out, thread id defaults to t0, core id defaults to c0,  processor
             id  defaults  to  p0,  and node id will be left undefined. Either
             each logical processor must belong to one and only one NUMA node,
             or no logical processors must belong to any NUMA nodes.


             Both increasing and decreasing <IdRange>s are allowed.


             NUMA node identifiers are system wide. That is, each NUMA node on
             the system have to have a unique  identifier.  Processor  identi‐
             fiers  are also system wide. Core identifiers are processor wide.
             Thread identifiers are core wide.


             The order of the identifier types imply the hierarchy of the  CPU
             topology.  Valid  orders  are either <LogicalIds><ThreadIds><Cor‐
             eIds><ProcessorIds><NodeIds>,   or   <LogicalIds><ThreadIds><Cor‐
             eIds><NodeIds><ProcessorIds>.  That  is, thread is part of a core
             which is part of a processor which is part of  a  NUMA  node,  or
             thread  is  part  of a core which is part of a NUMA node which is
             part of a processor. A cpu topology can consist of both processor
             external, and processor internal NUMA nodes as long as each logi‐
             cal processor belongs to one and only one NUMA node. If  <Proces‐
             sorIds>  is  left  out,  its  default  position  will  be  before
             <NodeIds>. That is, the default is processor external NUMA nodes.


             If a list of identifiers is used in an <IdDefs>:


             * <LogicalIds> have to be a list of identifiers.

             * At least one other identifier type apart from <LogicalIds> also
               have to have a list of identifiers.

             * All  lists  of  identifiers  have to produce the same amount of
               identifiers.

             A simple example. A single quad core processor may  be  described
             this way:


           % erl +sct L0-3c0-3
           1> erlang:system_info(cpu_topology).
           [{processor,[{core,{logical,0}},
                        {core,{logical,1}},
                        {core,{logical,2}},
                        {core,{logical,3}}]}]


             A little more complicated example. Two quad core processors. Each
             processor in its own NUMA node. The ordering of  logical  proces‐
             sors is a little weird. This in order to give a better example of
             identifier lists:


           % erl +sct L0-1,3-2c0-3p0N0:L7,4,6-5c0-3p1N1
           1> erlang:system_info(cpu_topology).
           [{node,[{processor,[{core,{logical,0}},
                               {core,{logical,1}},
                               {core,{logical,3}},
                               {core,{logical,2}}]}]},
            {node,[{processor,[{core,{logical,7}},
                               {core,{logical,4}},
                               {core,{logical,6}},
                               {core,{logical,5}}]}]}]


             As long as real identifiers are correct it is okay to pass a  CPU
             topology  that  is not a correct description of the CPU topology.
             When used with care this can actually be  very  useful.  This  in
             order  to  trick the emulator to bind its schedulers as you want.
             For example, if you want to run multiple Erlang  runtime  systems
             on  the same machine, you want to reduce the amount of schedulers
             used and manipulate the CPU topology so that they bind to differ‐
             ent  logical CPUs. An example, with two Erlang runtime systems on
             a quad core machine:


           % erl +sct L0-3c0-3 +sbt db +S3:2 -detached -noinput -noshell -sname one
           % erl +sct L3-0c0-3 +sbt db +S3:2 -detached -noinput -noshell -sname two


             In this example each runtime  system  have  two  schedulers  each
             online, and all schedulers online will run on different cores. If
             we change to one scheduler online  on  one  runtime  system,  and
             three  schedulers online on the other, all schedulers online will
             still run on different cores.


             Note that a faked CPU topology that does not reflect how the real
             CPU  topology looks like is likely to decrease the performance of
             the runtime system.


             For  more   information,   see   erlang:system_flag(cpu_topology,
             CpuTopology).


           +swt very_low|low|medium|high|very_high:
             Set  scheduler wakeup threshold. Default is medium. The threshold
             determines when to wake up sleeping  schedulers  when  more  work
             than  can  be  handled by currently awake schedulers exist. A low
             threshold will cause earlier wakeups, and a high  threshold  will
             cause later wakeups. Early wakeups will distribute work over mul‐
             tiple schedulers faster, but work will more easily bounce between
             schedulers.

             NOTE:  This  flag  may  be removed or changed at any time without
             prior notice.


           +sss size:
             Suggested stack size, in kilowords, for scheduler threads.  Valid
             range  is  4-8192  kilowords. The default stack size is OS depen‐
             dent.

         +t size:
           Set the maximum number of atoms  the  VM  can  handle.  Default  is
           1048576.

         +T Level:
           Enables  modified  timing  and sets the modified timing level. Cur‐
           rently valid range is 0-9. The timing of the  runtime  system  will
           change.  A  high  level  usually  means a greater change than a low
           level. Changing the timing can be very useful  for  finding  timing
           related bugs.

           Currently, modified timing affects the following:


           Process spawning:
             A  process calling spawn, spawn_link, spawn_monitor, or spawn_opt
             will be scheduled out immediately after completing the call. When
             higher  modified  timing  levels  are  used, the caller will also
             sleep for a while after being scheduled out.

           Context reductions:
             The amount of reductions a process is a  allowed  to  use  before
             being scheduled out is increased or reduced.

           Input reductions:
             The  amount  of  reductions  performed  before  checking  I/O  is
             increased or reduced.

           NOTE: Performance will suffer when modified timing is enabled. This
           flag  is  only  intended  for testing and debugging. Also note that
           return_to and return_from trace messages will be lost when  tracing
           on  the spawn BIFs. This flag may be removed or changed at any time
           without prior notice.


         +V:
           Makes the emulator print out its version number.

         +v:
           Verbose.

         +W w | i:
           Sets the mapping of warning  messages  for  error_logger.  Messages
           sent  to  the error logger using one of the warning routines can be
           mapped either to errors (default), warnings (+W w), or info reports
           (+W  i).  The  current  mapping  can  be retrieved using error_log‐
           ger:warning_map/0. See error_logger(3erl) for further information.

         +zFlag Value:
           Miscellaneous flags.

           +zdbbl size:
             Set the distribution buffer busy limit  (dist_buf_busy_limit)  in
             kilobytes. Valid range is 1-2097151. Default is 1024.

             A  larger buffer limit will allow processes to buffer more outgo‐
             ing messages over the distribution. When  the  buffer  limit  has
             been  reached, sending processes will be suspended until the buf‐
             fer size has shrunk. The buffer limit is per  distribution  chan‐
             nel. A higher limit will give lower latency and higher throughput
             at the expense of higher memory usage.


ENVIRONMENT VARIABLES
         ERL_CRASH_DUMP:
           If the emulator needs to write a crash  dump,  the  value  of  this
           variable will be the file name of the crash dump file. If the vari‐
           able is  not  set,  the  name  of  the  crash  dump  file  will  be
           erl_crash.dump in the current directory.

         ERL_CRASH_DUMP_NICE:
           Unix  systems: If the emulator needs to write a crash dump, it will
           use the value of this variable  to  set  the  nice  value  for  the
           process,  thus  lowering  its  priority.  The  allowable range is 1
           through 39 (higher values will be replaced with  39).  The  highest
           value, 39, will give the process the lowest priority.

         ERL_CRASH_DUMP_SECONDS:
           Unix  systems:  This  variable gives the number of seconds that the
           emulator will be allowed to spend writing a crash  dump.  When  the
           given  number  of seconds have elapsed, the emulator will be termi‐
           nated by a SIGALRM signal.

         ERL_AFLAGS:
           The content of this environment  variable  will  be  added  to  the
           beginning of the command line for erl.

           The  -extra flag is treated specially. Its scope ends at the end of
           the environment variable content.  Arguments  following  an  -extra
           flag  are  moved  on the command line into the -extra section, i.e.
           the end of the command line following after an -extra flag.


         ERL_ZFLAGSand ERL_FLAGS:
           The content of these environment variables will be added to the end
           of the command line for erl.

           The  -extra flag is treated specially. Its scope ends at the end of
           the environment variable content.  Arguments  following  an  -extra
           flag  are  moved  on the command line into the -extra section, i.e.
           the end of the command line following after an -extra flag.


         ERL_LIBS:
           This environment variable contains a  list  of  additional  library
           directories  that  the code server will search for applications and
           add to the code path. See code(3erl).

         ERL_EPMD_ADDRESS:
           This environment variable may be set to a comma-separated  list  of
           IP addresses, in which case the epmd daemon will listen only on the
           specified address(es) and on the loopback address (which is implic‐
           itly added to the list if it has not been specified).

         ERL_EPMD_PORT:
           This  environment  variable can contain the port number to use when
           communicating with epmd. The default port will work  fine  in  most
           cases. A different port can be specified to allow nodes of indepen‐
           dent clusters to co-exist on the same host. All nodes in a  cluster
           must use the same epmd port number.

CONFIGURATION
       The  standard  Erlang/OTP  system  can  be  re-configured to change the
       default behavior on start-up.

         The .erlang Start-up File:
           When Erlang/OTP is started, the system searches for  a  file  named
           .erlang in the directory where Erlang/OTP is started. If not found,
           the user's home directory is searched for an .erlang file.

           If an .erlang file is found, it is assumed to contain valid  Erlang
           expressions.  These expressions are evaluated as if they were input
           to the shell.


           A typical .erlang file contains a set of search paths, for example:


                 io:format("executing user profile in HOME/.erlang\n",[]).
                 code:add_path("/home/calvin/test/ebin").
                 code:add_path("/home/hobbes/bigappl-1.2/ebin").
                 io:format(".erlang rc finished\n",[]).


         user_default and shell_default:
           Functions in the shell which are not prefixed by a module name  are
           assumed to be functional objects (Funs), built-in functions (BIFs),
           or belong to the module user_default or shell_default.

           To  include  private  shell  commands,  define  them  in  a  module
           user_default  and  add  the following argument as the first line in
           the .erlang file.


                  code:load_abs("..../user_default").


         erl:
           If the contents of .erlang are changed and  a  private  version  of
           user_default is defined, it is possible to customize the Erlang/OTP
           environment. More powerful changes can be made by supplying command
           line  arguments  in  the  start-up  script erl. Refer to erl(1) and
           init(3erl) for further information.

SEE ALSO
       init(3erl), erl_prim_loader(3erl),  erl_boot_server(3erl),  code(3erl),
       application(3erl),     heart(3erl),    net_kernel(3erl),    auth(3erl),
       make(3erl), epmd(1), erts_alloc(3erl)



Ericsson AB                       erts 5.8.5                            erl(1)