From 57c3246511434f42214e113b8902af10ab9cca49 Mon Sep 17 00:00:00 2001 From: xsipewe Date: Tue, 21 Jun 2016 15:50:34 +0200 Subject: erts: Editorial changes --- erts/doc/src/erl.xml | 2226 +++++++++++++++++++++++++------------------------- 1 file changed, 1106 insertions(+), 1120 deletions(-) (limited to 'erts/doc/src/erl.xml') diff --git a/erts/doc/src/erl.xml b/erts/doc/src/erl.xml index 37387f2c59..5559aec30e 100644 --- a/erts/doc/src/erl.xml +++ b/erts/doc/src/erl.xml @@ -30,86 +30,92 @@ erl.xml erl - The Erlang Emulator + The Erlang emulator.

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

-

Windows users probably wants to use the program + The exact details (for example, whether is a + script or a program and which other programs it calls) are + system-dependent.

+ +

Windows users probably want to use the program instead, which runs in its own window with scrollbars and supports - command-line editing. The 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 program must be used, however, in pipelines or if + command-line editing. The program on Windows + provides no line editing in its shell, and on Windows 95 there is no way + to scroll back to text that has scrolled off the screen. The + program must be used, however, in pipelines or if you want to redirect standard input or output.

-

As of ERTS version 5.9 (OTP-R15B) the runtime system will by - default not bind schedulers to logical processors. - For more information see documentation of the - +sbt system flag. -

- + + +

As from ERTS 5.9 (Erlang/OTP R15B) the runtime system does by + default not bind schedulers to logical processors. + For more information, see system flag + +sbt.

+ + erl <arguments> - Start an Erlang runtime system + Start an Erlang runtime system. -

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 behavior 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 system process, see - init(3).

-

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

-

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 process and can be - retrieved by calling . - Plain arguments can occur before the first flag, or after - a flag. Additionally, the flag - causes everything that follows to become plain arguments.

- - -

Example:

- 
+	
Starts an Erlang runtime system.

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

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

+	    
As indicated by the name, emulator flags control
+	      the behavior of the emulator.

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

+	    
The  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 .

+	    
A small number of "-" flags exist, which now actually are
+	      emulator flags, see the description below.

+	  
+	  
+	    
Plain arguments are not interpreted in any way. They are also
+	      stored by the  process and can be retrieved
+	      by calling .
+	      Plain arguments can occur before the first flag, or after a
+	       flag. Also, the 
+	      flag causes everything that follows to become plain arguments.

+	  
+	
+	
Examples:

+	
 % 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  and  are emulator flags.
-           is an init flag, interpreted by .
-           is a user flag, stored by .
-          It is read by Kernel and will cause the Erlang runtime system
-          to become distributed. Finally, everything after 
-          (that is, ) is considered as plain arguments.

-        
+        
Here  and  are
+	  emulator flags.  is an init flag,
+	  interpreted by .
+	   is a user flag, stored by
+	  . It is read by Kernel and causes the
+	  Erlang runtime system to become distributed. Finally, everything after
+	   (that is, ) is
+	  considered as plain arguments.

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

-        
Here the user flag  is passed to and stored
-          by the  process. It is a user defined flag,
-          presumably used by some user defined application.

+        
Here the user flag  is passed to and
+	  stored by the  process. It is a user-defined
+	  flag, presumably used by some user-defined application.

       
     
   
@@ -117,50 +123,54 @@
   

     
     Flags
-    
In the following list, init flags are marked (init flag).
+    
In the following list, init flags are marked "(init flag)".
       Unless otherwise specified, all other flags are user flags, for
       which the values can be retrieved by calling
-      . Note that the list of user flags is
-      not exhaustive, there may be additional, application specific
-      flags which instead are documented in the corresponding
+      . Notice that the list of user
+      flags is not exhaustive, there can be more application-specific
+      flags that instead are doscribed in the corresponding
       application documentation.

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

+          ( or ) is considered
+          plain arguments and can be retrieved using
+          .

       
       
       
-        
Sets the application configuration parameter  to
-          the value  for the application ,
-          see app(4) and
-          application(3).

+        
Sets the application configuration parameter 
+          to the value  for the application
+          ; see
+          kernel:app(4) and
+          
+          kernel:application(3).

       
       
       
-        
Command line arguments are read from the file .
-          The arguments read from the file replace the
-          '' flag on the resulting command line.

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

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

+        
Command-line arguments are read from the file
+          . The arguments read from the file replace
+          flag '' on the resulting
+          command line.

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

+        
The flag  is treated in special way. Its
+          scope ends at the end of the file. Arguments following an
+           flag are moved on the command line into the
+           section, that is, the end of the command
+          line following after an  flag.

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

@@ -168,52 +178,56 @@
       
       
         
Specifies the name of the boot file, ,
-          which is used to start the system. See
-          init(3). Unless
+          which is used to start the system; see
+          init(3). Unless
            contains an absolute path, the system searches
-          for  in the current and 
-          directories.

+          for  in the current and 
+           directories.

         
Defaults to .

       
       
       
-        
If the boot script contains a path variable  other
-          than , this variable is expanded to .
-          Used when applications are installed in another directory
-          than , see
-          systools:make_script/1,2.

+        
If the boot script contains a path variable 
+          other than , this variable is expanded to
+          . Used when applications are installed in
+          another directory than ; see
+          
+          systools:make_script/1,2 in SASL.

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

+        
Enables the code path cache of the code server; see
+          kernel:code(3).

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

+          succeed). Implies .

+        
Not recommended; use erlc
+          instead.

       
       
       
         
Specifies the name of a configuration file,
           , which is used to configure
-          applications. See
-          app(4) and
-          application(3).

+          applications; see
+          kernel:app(4) and
+          
+          kernel:application(3).

       
       
       
-        
If this flag is present,  will not maintain a
-          fully connected network of distributed Erlang nodes, and then
-          global name registration cannot be used. See
-          global(3).

+        
If this flag is present,  does not maintain
+          a fully connected network of distributed Erlang nodes, and then
+          global name registration cannot be used; see
+          kernel:global(3).

       
       
       
         
Obsolete flag without any effect and common misspelling for
-          . Use  instead.

+          . Use 
+          instead.

       
       
       
@@ -223,8 +237,7 @@
       
       
       
-        
Useful for debugging. Prints out the actual arguments
-          sent to the emulator.

+        
Useful for debugging. Prints the arguments sent to the emulator.

       
       
       
@@ -234,14 +247,16 @@
         
 % erl -env DISPLAY gin:0

         
In this example, an Erlang runtime system is started with
-          the  environment variable set to .

+          environment variable  set to
+          .

       
-      (init flag)
+       (init flag)
       
-        
Makes  evaluate the expression , see
-          init(3).

+        
Makes  evaluate the expression
+          ; see
+          init(3).

       
-      (init flag)
+       (init flag)
       
         
Everything following  is considered plain
           arguments and can be retrieved using
@@ -249,8 +264,9 @@
       
       
       
-        
Starts heart beat monitoring of the Erlang runtime system.
-          See heart(3).

+        
Starts heartbeat monitoring of the Erlang runtime system;
+          see 
+          kernel:heart(3).

       
       
       
@@ -258,91 +274,99 @@
           run as a distributed node. Hidden nodes always establish
           hidden connections 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  on the other
-          node. See also hidden global groups,
-          global_group(3).

+          any of the connected nodes, that is, none of the connected
+          nodes are part of the result from  on the
+          other node. See also hidden global groups;
+          
+          kernel:global_group(3).

       
       
       
-        
Specifies the IP addresses for the hosts on which Erlang
-          boot servers are running, see
-          erl_boot_server(3).
-          This flag is mandatory if the  flag is
-          present.

-        
The IP addresses must be given in the standard form (four
-          decimal numbers separated by periods, for example
-          . Hosts names are not acceptable, but
-          a broadcast address (preferably limited to the local network)
+        
Specifies the IP addresses for the hosts on which Erlang boot servers
+          are running, see 
+          kernel:erl_boot_server(3). This flag
+          is mandatory if flag  is present.

+        
The IP addresses must be specified in the standard form (four
+          decimal numbers separated by periods, for example,
+          . Hosts names are not acceptable,
+          but a broadcast address (preferably limited to the local network)
           is.

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

+          the name supplied together with flag  or
+          .

       
       
       
         
Makes  write some debug information while
           interpreting the boot script.

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

       
       
       
-        
Specifies the method used by  to load
-          Erlang modules into the system. See
-          erl_prim_loader(3).
-          Two  methods are supported,  and
-          .  means use the local file system,
-          this is the default.  means use a boot server on
-          another machine, and the ,  and
-           flags must be specified as well. If
-           is something else, the user supplied
+        
Specifies the method used by  to
+          load Erlang modules into the system; see
+          erl_prim_loader(3).
+          Two  methods are supported:

+        
+          
+            
, which means use the local file system,
+              this is the default.

+          
+          
+            
, which means use a boot server on
+              another machine. The flags ,
+               and  must
+              also be specified.

+          
+        
+        
If  is something else, the user-supplied
            port program is started.

       
       
       
-        
Makes the Erlang runtime system invoke  in
-          the current working directory and then terminate. See
-          make(3). Implies
+        
Makes the Erlang runtime system invoke 
+          in the current working directory and then terminate; see
+          tools:make(3). Implies
           .

       
       
       
-        
Displays the manual page for the Erlang module .
-          Only supported on Unix.

+        
Displays the manual page for the Erlang module
+          . Only supported on Unix.

       
       
       
-        
Indicates if the system should load code dynamically
-          (), or if all code should be loaded
-          during system initialization (), see
-          code(3). Defaults to
-          .

+        
Indicates if the system is to load code dynamically
+          (), or if all code is to be loaded
+          during system initialization (); see
+          kernel:code(3).
+          Defaults to .

       
       
       
         
Makes the Erlang runtime system into a distributed node.
           This flag invokes all network servers necessary for a node to
-          become distributed. See
-          net_kernel(3).
-          It is also ensured that  runs on the current host
-          before Erlang is started. See
-          epmd(1) and the
+          become distributed; see 
+          kernel:net_kernel(3). It is also ensured that
+           runs on the current host before Erlang is
+          started; see epmd(1).and the
           -start_epmd option.

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

+        
The node name will be , where
+           is the fully qualified host name of the
+          current host. For short names, use flag 
+          instead.

       
       
       
@@ -353,115 +377,111 @@
       
         
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.

+          component in a series of Unix pipes.

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

+          server; see
+          kernel:code(3).

       
       
       
-        
Invokes the old Erlang shell from Erlang 3.3. The old shell
+        
Invokes the old Erlang shell from Erlang/OTP 3.3. The old shell
           can still be used.

       
       
       
         
Adds the specified directories to the beginning of the code
-          path, similar to . See
-          code(3).
+          path, similar to ; see
+          kernel:code(3).
 	  As an alternative to -pa, if several directories are
 	  to be prepended to the code path and the directories have a
-	  common parent directory, that parent directory could be
-	  specified in the ERL_LIBS environment variable.
-	  See code(3).

+	  common parent directory, that parent directory can be
+	  specified in environment variable ERL_LIBS; see
+	  kernel:code(3).

       
       
       
         
Adds the specified directories to the end of the code path,
-          similar to . See
-          code(3).

+          similar to ; see
+          kernel:code(3).

       
       
       
-        
Replaces the path specified in the boot script. See
-          script(4).

+        
Replaces the path specified in the boot script; see
+          sasl:script(4).

       
       
       
-        
Specify a protocol for Erlang distribution.

-	    
-	      inet_tcp
-              
-                  
TCP over IPv4 (the default)

-              
-	      inet_tls
-              
-                  
distribution over TLS/SSL

-              
-	      inet6_tcp
-              
-                  
TCP over IPv6

-              
+        
Specifies a protocol for Erlang distribution:

+        
+          inet_tcp
+          TCP over IPv4 (the default)
+          inet_tls
+          Distribution over TLS/SSL
+          inet6_tcp
+          TCP over IPv6
         
         
For example, to start up IPv6 distributed nodes:

 
-% erl -name test@ipv6node.example.com -proto_dist inet6_tcp
-

+% erl -name test@ipv6node.example.com -proto_dist inet6_tcp

       
       
       
-        
Starts Erlang with a remote shell connected to .

+        
Starts Erlang with a remote shell connected to
+          .

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

+        
Specifies an alternative to  for starting a
+          slave node on a remote host; see
+          stdlib:slave(3).

       
-      (init flag)
+       (init
+        flag)
       
-        
Makes  call the specified function. 
-          defaults to . 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
-           as argument. All arguments are passed
-          as strings. See
-          init(3).

+        
Makes  call the specified function.
+           defaults to .
+          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
+           as argument. All arguments are
+          passed as strings. See 
+          init(3).

       
-      (init flag)
+       (init flag)
       
-        
Makes  call the specified function. 
-          defaults to . 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
-           as argument. All arguments are passed
-          as atoms. See
-          init(3).

+        
Makes  call the specified function.
+           defaults to .
+          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
+           as argument. All arguments are
+          passed as atoms. See 
+          init(3).

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

+        
Sets the magic cookie of the node to ; see
+          
+          erlang:set_cookie/2.

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

+           milliseconds have elapsed, all processes still
+          existing are killed. Defaults to .

       
       
       
-        
Makes the Erlang runtime system into a distributed node,
-          similar to , but the host name portion of the node
+        
Makes the Erlang runtime system into a distributed node, similar to
+          , but the host name portion of the node
           name  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 
-          flag and those running with the  flag, as node
+          the Domain Name System (DNS) is not running. No communication can
+          exist between nodes running with flag 
+          and those running with flag , as node
           names must be unique in distributed Erlang systems.

       
       -start_epmd true | false
@@ -481,19 +501,21 @@
       
       
       
-        
-smp enable and -smp starts the Erlang runtime
-	  system with SMP support enabled. This may fail if no runtime
+        
-smp enable and -smp start the Erlang runtime
+	  system with SMP support enabled. This can 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 processor are detected.
+	  available and more than one logical processor is detected.
 	  -smp disable starts a runtime system without SMP support.

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

+        
+          
The runtime system with SMP support is not available on all
+            supported platforms. See also flag
+            +S.

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

       
     
@@ -505,133 +527,169 @@
     
 invokes the code for the Erlang emulator (virtual
       machine), which supports the following flags:

     
-      
+      
+        
       
         
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
+          async thread pool. Valid range is 16-8192 kilowords. The
+          default suggested stack size is 16 kilowords, that is, 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 drivers
-          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.

+          has been chosen because the number of async threads can
+          be large. The default size is enough for drivers
+          delivered with Erlang/OTP, but might not be large
+          enough for other dynamically linked-in drivers that use the
+          
+          driver_async() functionality.
+          Notice that the value passed is only a suggestion,
+          and it can even be ignored on some platforms.

       
       
       
-        
Sets the number of threads in async thread pool, valid range
-          is 0-1024. If thread support is available, the default is 10.

+        
Sets the number of threads in async thread pool. Valid range
+          is 0-1024. Defaults to 10 if thread support is available.

       
       
       
-        
The  option makes  interrupt the current
-          shell instead of invoking the emulator break handler.
-          The  option (same as specifying  without an
-          extra option) disables the break handler. The  option
-          makes the emulator ignore any break signal.

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

-        
Note that on Windows, this flag is only applicable for 
-          , not  (). Note also that
-           is used instead of  on Windows.

+        
Option  makes 
+          interrupt the current shell instead of invoking the emulator break
+          handler. Option  (same as specifying
+           without an extra option) disables the break
+          handler. Option  makes the emulator ignore any
+          break signal.

+        
If option  is used with
+           on Unix,  will
+          restart the shell process rather than interrupt it.

+        
Notice that on Windows, this flag is only applicable for
+          , not 
+          (). Notice also that
+           is used instead of
+           on Windows.

       
       
       
-        
Enable or disable
-	time correction:

+        
Enables or disables
+          time
+          correction:

 	
 	  true
-	  
Enable time correction. This is the default if
-	  time correction is supported on the specific platform.

-
-	  false
-	  
Disable time correction.

-	
-	
For backwards compatibility, the boolean value can be omitted.
-	This is interpreted as +c false.
-	

-      
-      
-      
-        
Set
-	time warp mode:
-	

-	
-	  no_time_warp
-	  
No Time Warp Mode (the default)

-	  single_time_warp
-	  
Single Time Warp Mode

-	  multi_time_warp
-	  
Multi Time Warp Mode

-	
+          Enables time correction. This is the default if
+            time correction is supported on the specific platform.
+          false
+          Disables time correction.
+          
+        
For backward compatibility, the boolean value can be omitted.
+          This is interpreted as +c false.

+      
+      erlang:now()ime_warp | single_time_warp |
+        multi_time_warp]]>
+      
+        
Sets time warp
+          mode:

+        
+        no_time_warp
+          
+            No time warp mode (the default)
+          single_time_warp
+          
+            Single time warp mode
+          multi_time_warp
+          
+            Multi-time warp mode
+      
       
       
       
         
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. On Unix systems, sending an emulator process
-	a SIGUSR1 signal will also force a crash dump.

+          it, by default, generates both a crash dump and a core dump.
+          The core dump is, however, not very useful as the content
+          of process heaps is destroyed by the crash dump generation.

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

+        
Calling 
+          erlang:halt/1 with a string argument still
+          produces a crash dump. On Unix systems, sending an emulator process
+          a SIGUSR1 signal also forces a crash dump.

       
       
       
-        
Set max number of ETS tables.

+        
Sets the maximum number of ets tables.

       
       
       
-        
Force the compressed option on all ETS tables.
-              Only intended for test and evaluation.

+        
Forces option compressed on all ets tables.
+          Only intended for test and evaluation.

       
-      
+      
+        
       
-        
The VM works with file names as if they are encoded using the ISO-latin-1 encoding, disallowing Unicode characters with codepoints beyond 255.

-	
See STDLIB User's Guide for more infomation about unicode file names. Note that this value also applies to command-line parameters and environment variables (see STDLIB User's Guide).

+        
The virtual machine works with filenames as if they are encoded
+          using the ISO Latin-1 encoding, disallowing Unicode characters with
+          code points > 255.

+        
For more information about Unicode filenames, see section
+          Unicode
+          Filenames in the STDLIB User's Guide. Notice that
+          this value also applies to command-line parameters and environment
+          variables (see section 
+          Unicode in Enviroment and Parameters in the STDLIB
+          User's Guide).

       
       
       
-        
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 MacOS X.

-	
The +fnu switch can be followed by w,
-	i, or e to control the way wrongly encoded file
-	names are to be reported. w means that a warning is
-	sent to the error_logger whenever a wrongly encoded
-	file name is "skipped" in directory listings, i means
-	that those wrongly encoded file names are silently ignored and
-	e means that the API function will return an error
-	whenever a wrongly encoded file (or directory) name is
-	encountered. w is the default. Note that
-	file:read_link/1 will always return an error if the
-	link points to an invalid file name.

-	
See STDLIB User's Guide for more infomation about unicode file names. Note that this value also applies to command-line parameters and environment variables (see STDLIB User's Guide).

+        
The virtual machine works with filenames 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, that
+          is, Windows and MacOS X.

+        
The +fnu switch can be followed by w, i, or
+          e to control how wrongly encoded filenames are to be
+          reported:

+        
+          
+            
w means that a warning is sent to the error_logger
+              whenever a wrongly encoded filename is "skipped" in directory
+              listings. This is the default.

+          
+          
+            
i means that those wrongly encoded filenames are silently
+              ignored.

+          
+          
+            
e means that the API function returns an error whenever a
+              wrongly encoded filename (or directory name) is encountered.

+          
+        
+        
Notice that 
+          file:read_link/1 always returns an error if the link
+          points to an invalid filename.

+        
For more information about Unicode filenames, see section
+          Unicode
+          Filenames in the STDLIB User's Guide. Notice that
+          this value also applies to command-line parameters and environment
+          variables (see section 
+          Unicode in Enviroment and Parameters in the STDLIB
+          User's Guide).

       
       
       
         
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 file names. This is
-        default on all operating systems except MacOS X and
-        Windows.

-	
The +fna switch can be followed by w,
-	i, or e. This will have effect if the locale
-	settings cause the behavior of +fnu to be selected.
-	See the description of +fnu above. If the locale
-	settings cause the behavior of +fnl to be selected,
-	then w, i, or e will not have any
-	effect.

-	
See STDLIB User's Guide for more infomation about unicode file names. Note that this value also applies to command-line parameters and environment variables (see STDLIB User's Guide).

+          on the current locale settings in the OS. This means that if you
+          have set your terminal for UTF-8 encoding, the filesystem is
+          expected to use the same encoding for filenames. This is
+          default on all operating systems, except MacOS X and Windows.

+        
The +fna switch can be followed by w, i, or
+          e. This has effect if the locale settings cause the behavior
+          of +fnu to be selected; see the description of +fnu
+          above. If the locale settings cause the behavior of +fnl to be
+          selected, then w, i, or e have no effect.

+        
For more information about Unicode filenames, see section
+          Unicode
+          Filenames in the STDLIB User's Guide. Notice that
+          this value also applies to command-line parameters and environment
+          variables (see section 
+          Unicode in Enviroment and Parameters in the STDLIB
+          User's Guide).

       
       
       
@@ -646,26 +704,24 @@
       
       
         
Sets the default maximum heap size of processes to the size
-          . If +hmax is not given, the default is 0
-          which means that no maximum heap size is used.
-          For more information, see the documentation of
+          . Defaults to 0, which means that no
+          maximum heap size is used. For more information, see
           
-            process_flag(max_heap_size, MaxHeapSize).

+          process_flag(max_heap_size, MaxHeapSize).

       
       
       
-        
Sets whether to send an error logger message for processes that reach
-        the maximum heap size or not. If +hmaxel is not given, the default is true.
-        For more information, see the documentation of
-        
+        
Sets whether to send an error logger message or not for processes
+          reaching the maximum heap size. Defaults to true.
+          For more information, see
+          
           process_flag(max_heap_size, MaxHeapSize).

       
       
       
-        
Sets whether to kill processes that reach the maximum heap size or not. If
-        +hmaxk is not given, the default is true. For more information,
-	see the documentation of
-        
+        
Sets whether to kill processes reaching the maximum heap size or not.
+          Default to true. For more information, see
+          
           process_flag(max_heap_size, MaxHeapSize).

       
       
@@ -674,304 +730,231 @@
           .

       
       +hmqd off_heap|on_heap
-      

-	Sets the default value for the process flag
-	message_queue_data. If +hmqd is not
-	passed, on_heap will be the default. For more information,
-	see the documentation of
-        process_flag(message_queue_data,
-	MQD).
-      

+      
+        
Sets the default value for process flag message_queue_data.
+          Defaults to on_heap. If +hmqd is not
+	  passed, on_heap will be the default. For more information, see
+          
+          process_flag(message_queue_data, MQD).

+      
       
       
-        
Enables or disables the kernel poll functionality if
-          the emulator supports it. Default is  (disabled).
-          If the emulator does not support kernel poll, and
-          the  flag is passed to the emulator, a warning is
+        
Enables or disables the kernel poll functionality if supported by
+          the emulator. Defaults to  (disabled).
+          If the emulator does not support kernel poll, and flag
+           is passed to the emulator, a warning is
           issued at startup.

       
       
       
-        
Enables auto load tracing, displaying info while loading
+        
Enables autoload tracing, displaying information while loading
           code.

       
       
       
-        
Don't load information about source file names and line numbers.
-	  This will save some memory, but exceptions will not contain
-	  information about the file names and line numbers.
-          

+        
Prevents loading information about source filenames and line
+          numbers. This saves some memory, but exceptions do not contain
+          information about the filenames and line numbers.

       
       
       
-        
Memory allocator specific flags, see
-          erts_alloc(3) for
-          further information.

-      
-      
-      
-	
Control behavior of signals to ports.

-	
As of OTP-R16 signals to ports are truly asynchronously
-	   delivered. Note that signals always have been documented as
-	   asynchronous. The underlying implementation has, however,
-	   previously delivered these signals synchronously. Correctly
-	   written Erlang programs should be able to handle this without
-	   any issues. Bugs in existing Erlang programs that make false
-	   assumptions about signals to ports may, however, be tricky to
-	   find. This switch has been introduced in order to at least
-	   make it easier to compare behaviors during a transition period.
-	   Note that this flag is deprecated as of its
-	   introduction, and is scheduled for removal in OTP-R17.
-	   Behavior should be one of the following characters:

-	   
-	     d
-	     The default. Asynchronous signals. A process that sends
-	     a signal to a port may continue execution before the signal
-	     has been delivered to the port.
-	     s
-	     Synchronous signals. A processes that sends a signal
-	     to a port will not continue execution until the signal has
-	     been delivered. Should only be used for testing and
-	     debugging.
-	     a
-	     Asynchronous signals. As the default, but a processes
-	     that sends a signal will even more frequently continue
-	     execution before the signal has been delivered to the
-	     port. Should only be used for testing and
-	     debugging.
-	   
-      
-      
-      
-	
Sets the range of characters that the system will consider printable in heuristic detection of strings. This typically affects the shell, debugger and io:format functions (when ~tp is used in the format string).
 
-	
Currently two values for the Range are supported:

-	
-	  latin1 The default. Only characters
-	  in the ISO-latin-1 range can be considered printable, which means
-	  that a character with a code point > 255 will never be
-	  considered printable and that lists containing such
-	  characters will be displayed as lists of integers rather
-	  than text strings by tools.
-	  unicode
-	  All printable Unicode characters are considered when
-	  determining if a list of integers is to be displayed in
-	  string syntax. This may give unexpected results if for
-	  example your font does not cover all Unicode
-	  characters.
-	
-	
Se also 
-	io:printable_range/0.

-      
-      
-      
-	
Sets the maximum number of simultaneously existing processes for this
-          system if a Number is passed as value. Valid range for
-	Number is [1024-134217727]

-	
NOTE: The actual maximum chosen may be much larger than
-	the Number passed. Currently the runtime system often,
-	but not always, chooses a value that is a power of 2. This might,
-	however, be changed in the future. The actual value chosen can be
-	checked by calling
-	erlang:system_info(process_limit).

-	
The default value is 262144

-	
If legacy is passed as value, the legacy algorithm for
-	allocation of process identifiers will be used. Using the legacy
-	algorithm, identifiers will be allocated in a strictly increasing
-	fashion until largest possible identifier has been reached. Note that
-	this algorithm suffers from performance issues and can under certain
-	circumstances be extremely expensive. The legacy algoritm is deprecated,
-	and the legacy option is scheduled for removal in OTP-R18.

-      
-      
-      
-	
Sets the maximum number of simultaneously existing ports for this
-          system if a Number is passed as value. Valid range for Number
-	is [1024-134217727]

-	
NOTE: The actual maximum chosen may be much larger than
-	the actual Number passed. Currently the runtime system often,
-	but not always, chooses a value that is a power of 2. This might,
-	however, be changed in the future. The actual value chosen can be
-	checked by calling
-	erlang:system_info(port_limit).

-	
The default value used is normally 65536. However, if
-	the runtime system is able to determine maximum amount of file
-	descriptors that it is allowed to open and this value is larger
-	than 65536, the chosen value will increased to a value
-	larger or equal to the maximum amount of file descriptors that
-	can be opened.

-	
On Windows the default value is set to 8196 because the 
-	normal OS limitations are set higher than most machines can handle.

-	
Previously the environment variable ERL_MAX_PORTS was used
-	for setting the maximum number of simultaneously existing ports. This
-	environment variable is deprecated, and scheduled for removal in
-	OTP-R17, but can still be used.

-	
If legacy is passed as value, the legacy algorithm for
-	allocation of port identifiers will be used. Using the legacy
-	algorithm, identifiers will be allocated in a strictly increasing
-	fashion until largest possible identifier has been reached. Note that
-	this algorithm suffers from performance issues and can under certain
-	circumstances be extremely expensive. The legacy algoritm is deprecated,
-	and the legacy option is scheduled for removal in OTP-R18.

+        
Memory allocator-specific flags. For more information, see
+          erts_alloc(3).

+      
+      
+        
+      
+        
Sets the range of characters that the system considers printable in
+          heuristic detection of strings. This typically affects the shell,
+          debugger, and io:format functions (when ~tp is used in
+          the format string).
 
+        
Two values are supported for Range:

+        
+          latin1
+          The default. Only characters in the ISO Latin-1 range can be
+            considered printable. This means that a character with a code point
+            > 255 is never considered printable and that lists containing
+            such characters are displayed as lists of integers rather than text
+            strings by tools.
+          unicode
+          All printable Unicode characters are considered when
+            determining if a list of integers is to be displayed in
+            string syntax. This can give unexpected results if, for
+            example, your font does not cover all Unicode characters.
+        
+        
See also 
+          io:printable_range/0 in STDLIB.

       
       
       
         
Sets the compatibility mode.

-        
The distribution mechanism is not backwards compatible by
-          default. This flags sets the emulator in compatibility mode
+        
The distribution mechanism is not backward compatible by
+          default. This flag sets the emulator in compatibility mode
           with an earlier Erlang/OTP release .
           The release number must be in the range
           -2..]]>. 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.

-        
Note: Make sure all nodes (Erlang-,  C-, and Java nodes) of
-          a distributed 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.

+          limits the emulator, making it possible for it to communicate
+          with Erlang nodes (as well as C- and Java nodes) running that
+          earlier release.

+        
+          
Ensure that all nodes (Erlang-,  C-, and Java nodes) of
+            a distributed 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.

+        
       
       
       
-        
Force ets memory block to be moved on realloc.

+        
Forces ets memory block to be moved on realloc.

       
       
       
-        
Limits the amount of reader groups used by read/write locks
-	   optimized for read operations in the Erlang runtime system. By
-	   default the reader groups limit equals 64.

-	
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,
-	   schedulers 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 operations. 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 processors, since the reader groups
-	   are distributed better between schedulers.

-      
-      
-      
-        
Sets the number of scheduler threads to create and scheduler
-	  threads to set online when SMP support has been enabled. The maximum for
-	  both values is 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 number of schedulers
-	  online can be changed at run time via
-	  erlang:system_flag(schedulers_online, SchedulersOnline).
-	

-	
If Schedulers or SchedulersOnline is specified as a
-	  negative number, the value is subtracted from the default number of
-	  logical processors configured or logical processors available, respectively.
-	

-	
Specifying the value 0 for Schedulers or SchedulersOnline
-	  resets the number of scheduler threads or scheduler threads online respectively
-	  to its default value.
-	

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

-      
-      
-      
-        
Similar to +S but uses percentages to set the
-	  number of scheduler threads to create, based on logical processors configured,
-	  and scheduler threads to set online, based on logical processors available, when
-	  SMP support has been enabled. Specified values must be greater than 0. For example,
-	  +SP 50:25 sets the number of scheduler threads to 50% of the logical processors
-	  configured and the number of scheduler threads online to 25% of the logical processors available.
-	  SchedulersPercentage may be omitted if :SchedulersOnlinePercentage is
-	  not and vice versa. The number of schedulers online can be changed at run time via
-	  erlang:system_flag(schedulers_online, SchedulersOnline).
-	

-	
This option interacts with +S settings.
-	  For example, on a system with 8 logical cores configured and 8 logical cores
-	  available, the combination of the options +S 4:4 +SP 50:25 (in either order)
-	  results in 2 scheduler threads (50% of 4) and 1 scheduler thread online (25% of 4).
-	

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

-      
-      
-      
-          
Sets the number of dirty CPU scheduler threads to create and dirty
-            CPU scheduler threads to set online when threading support has been
-            enabled. The maximum for both values is 1024, and each value is further
-            limited by the settings for normal schedulers: the number of dirty CPU
-            scheduler threads created cannot exceed the number of normal scheduler
-            threads created, and the number of dirty CPU scheduler threads online
-            cannot exceed the number of normal scheduler threads online (see the
-            +S and +SP
-            flags for more details). By default, the number of dirty CPU scheduler
-            threads created equals the number of normal scheduler threads created,
-            and the number of dirty CPU scheduler threads online equals the number
-            of normal scheduler threads online. DirtyCPUSchedulers may be
-            omitted if :DirtyCPUSchedulersOnline is not and vice versa. The
-            number of dirty CPU schedulers online can be changed at run time via
-            erlang:system_flag(dirty_cpu_schedulers_online, DirtyCPUSchedulersOnline).
-          

-	  

-	    The amount of dirty CPU schedulers is limited by the amount of
-	    normal schedulers in order to limit the effect on processes
-	    executing on ordinary schedulers. If the amount of dirty CPU
-	    schedulers was allowed to be unlimited, dirty CPU bound jobs would
-	    potentially starve normal jobs.
-	  

-          
This option is ignored if the emulator doesn't have threading support
-            enabled. Currently, this option is experimental and is supported only
-            if the emulator was configured and built with support for dirty schedulers
-            enabled (it's disabled by default).
-          

-      
-      
-      
-          
Similar to +SDcpu but uses percentages to set the
-            number of dirty CPU scheduler threads to create and number of dirty CPU scheduler threads
-            to set online when threading support has been enabled. Specified values must be greater
-            than 0. For example, +SDPcpu 50:25 sets the number of dirty CPU scheduler threads
-            to 50% of the logical processors configured and the number of dirty CPU scheduler threads
-            online to 25% of the logical processors available. DirtyCPUSchedulersPercentage may
-            be omitted if :DirtyCPUSchedulersOnlinePercentage is not and vice versa. The
-            number of dirty CPU schedulers online can be changed at run time via
-            erlang:system_flag(dirty_cpu_schedulers_online, DirtyCPUSchedulersOnline).
-          

-          
This option interacts with +SDcpu settings.
-            For example, on a system with 8 logical cores configured and 8 logical cores available,
-            the combination of the options +SDcpu 4:4 +SDPcpu 50:25 (in either order) results
-            in 2 dirty CPU scheduler threads (50% of 4) and 1 dirty CPU scheduler thread online (25% of 4).
-          

-          
This option is ignored if the emulator doesn't have threading support
-            enabled. Currently, this option is experimental and is supported only
-            if the emulator was configured and built with support for dirty schedulers
-            enabled (it's disabled by default).
-          

+        
Limits the number of reader groups used by read/write locks
+          optimized for read operations in the Erlang runtime system. By
+          default the reader groups limit is 64.

+        
When the number of schedulers is less than or equal to the reader
+          groups limit, each scheduler has its own reader group. When the
+          number of schedulers is larger than the reader groups limit,
+          schedulers share reader groups. Shared reader groups degrade
+          read lock and read unlock performance while many
+          reader groups degrade write lock performance. So, the limit is a
+          tradeoff between performance for read operations and performance
+          for write operations. Each reader group consumes 64 byte
+          in each read/write lock.

+        
Notice that a runtime system using shared reader groups benefits from
+          binding schedulers to logical
+          processors, as the reader groups are distributed better
+          between schedulers.

+      
+      
+        
+      
+        
Sets the number of scheduler threads to create and scheduler threads
+          to set online when SMP support has been enabled. The maximum for both
+          values is 1024. If the Erlang runtime system is able to determine the
+          number of logical processors configured and logical processors
+          available, Schedulers defaults to logical processors
+          configured, and SchedulersOnline defaults to logical processors
+          available; otherwise the default values are 1. Schedulers can
+          be omitted if :SchedulerOnline is not and conversely. The
+          number of schedulers online can be changed at runtime through
+          
+          erlang:system_flag(schedulers_online,
+          SchedulersOnline).

+        
If Schedulers or SchedulersOnline is specified as a
+          negative number, the value is subtracted from the default number of
+          logical processors configured or logical processors available,
+          respectively.

+        
Specifying value 0 for Schedulers or
+          SchedulersOnline resets the number of scheduler threads or
+          scheduler threads online, respectively, to its default value.

+        
This option is ignored if the emulator does not have SMP support
+          enabled (see flag -smp).

+      
+      
+      
+        
Similar to +S but uses
+          percentages to set the number of scheduler threads to create, based
+          on logical processors configured, and scheduler threads to set online,
+          based on logical processors available, when SMP support has been
+          enabled. Specified values must be > 0. For example,
+          +SP 50:25 sets the number of scheduler threads to 50% of the
+          logical processors configured, and the number of scheduler threads
+          online to 25% of the logical processors available.
+          SchedulersPercentage can be omitted if
+          :SchedulersOnlinePercentage is not and conversely. The number
+          of schedulers online can be changed at runtime through
+          
+          erlang:system_flag(schedulers_online,
+          SchedulersOnline).

+        
This option interacts with +S
+          settings. For example, on a system with 8 logical cores configured
+          and 8 logical cores available, the combination of the options
+          +S 4:4 +SP 50:25 (in either order) results in 2 scheduler
+          threads (50% of 4) and 1 scheduler thread online (25% of 4).

+        
This option is ignored if the emulator does not have SMP support
+          enabled (see flag -smp).

+      
+      
+      
+        
Sets the number of dirty CPU scheduler threads to create and dirty
+          CPU scheduler threads to set online when threading support has been
+          enabled. The maximum for both values is 1024, and each value is
+          further limited by the settings for normal schedulers:

+        
+          The number of dirty CPU scheduler threads created cannot exceed
+            the number of normal scheduler threads created.
+          The number of dirty CPU scheduler threads online cannot exceed
+            the number of normal scheduler threads online.
+        
+        
For details, see the +S and
+          +SP. By default, the number
+          of dirty CPU scheduler threads created equals the number of normal
+          scheduler threads created, and the number of dirty CPU scheduler
+          threads online equals the number of normal scheduler threads online.
+          DirtyCPUSchedulers can be omitted if
+          :DirtyCPUSchedulersOnline is not and conversely. The number of
+          dirty CPU schedulers online can be changed at runtime through
+          
+          erlang:system_flag(dirty_cpu_schedulers_online,
+          DirtyCPUSchedulersOnline).

+	
The amount of dirty CPU schedulers is limited by the amount of
+	  normal schedulers in order to limit the effect on processes
+	  executing on ordinary schedulers. If the amount of dirty CPU
+	  schedulers was allowed to be unlimited, dirty CPU bound jobs would
+	  potentially starve normal jobs.

+        
This option is ignored if the emulator does not have threading
+          support enabled. This option is experimental and
+          is supported only if the emulator was configured and built with
+          support for dirty schedulers enabled (it is disabled by default).

+      
+      
+      
+        
Similar to +SDcpu but
+          uses percentages to set the number of dirty CPU scheduler threads to
+          create and the number of dirty CPU scheduler threads to set online
+          when threading support has been enabled. Specified values must be
+          > 0. For example, +SDPcpu 50:25 sets the number of dirty
+          CPU scheduler threads to 50% of the logical processors configured
+          and the number of dirty CPU scheduler threads online to 25% of the
+          logical processors available. DirtyCPUSchedulersPercentage can
+          be omitted if :DirtyCPUSchedulersOnlinePercentage is not and
+          conversely. The number of dirty CPU schedulers online can be changed
+          at runtime through
+          
+          erlang:system_flag(dirty_cpu_schedulers_online,
+          DirtyCPUSchedulersOnline).

+        
This option interacts with +SDcpu settings. For example, on a
+          system with 8 logical cores configured and 8 logical cores available,
+          the combination of the options +SDcpu 4:4 +SDPcpu 50:25 (in
+          either order) results in 2 dirty CPU scheduler threads (50% of 4) and
+          1 dirty CPU scheduler thread online (25% of 4).

+        
This option is ignored if the emulator does not have threading
+          support enabled. This option is experimental and
+          is supported only if the emulator was configured and built with
+          support for dirty schedulers enabled (it is disabled by default).

       
       
       
-          
Sets the number of dirty I/O scheduler threads to create when threading
-            support has been enabled. The valid range is 0-1024. By default, the number
-            of dirty I/O scheduler threads created is 10, same as the default number of
-            threads in the async thread pool
-            .
-          

-	  

-	    The amount of dirty IO schedulers is not limited by the amount of
-	    normal schedulers like the amount of
-	    dirty CPU schedulers. This since only I/O bound work is
-	    expected to execute on dirty I/O schedulers. If the user should schedule CPU
-	    bound jobs on dirty I/O schedulers, these jobs might starve ordinary
-	    jobs executing on ordinary schedulers.
-	  

-          
This option is ignored if the emulator doesn't have threading support
-            enabled. Currently, this option is experimental and is supported only
-            if the emulator was configured and built with support for dirty schedulers
-            enabled (it's disabled by default).
-          

+        
Sets the number of dirty I/O scheduler threads to create when
+          threading support has been enabled. Valid range is 0-1024. By
+          default, the number of dirty I/O scheduler threads created is 10,
+          same as the default number of threads in the async thread pool.

+	
The amount of dirty IO schedulers is not limited by the amount of
+	  normal schedulers like the amount of
+	  dirty CPU schedulers. This since only I/O bound work is
+	  expected to execute on dirty I/O schedulers. If the user should schedule CPU
+	  bound jobs on dirty I/O schedulers, these jobs might starve ordinary
+	  jobs executing on ordinary schedulers.

+        
This option is ignored if the emulator does not have threading
+          support enabled. This option is experimental and
+          is supported only if the emulator was configured and built with
+          support for dirty schedulers enabled (it is disabled by default).

       
       
       
@@ -979,238 +962,237 @@
         
           +sbt BindType
           
-            
Set scheduler bind type.

-	    
Schedulers can also be bound using the
-	    +stbt flag. The only difference
-	    between these two flags is how the following errors are handled:

-	    
-	      Binding of schedulers is not supported on the specific
-	      platform.
-	      No available CPU topology. That is the runtime system
-	      was not able to automatically detected the CPU topology, and
-	      no user defined CPU topology
-	      was set.
-	    
-	    
If any of these errors occur when +sbt has been passed,
-	    the runtime system will print an error message, and refuse to
-	    start. If any of these errors occur when +stbt has been
-	    passed, the runtime system will silently ignore the error, and
-	    start up using unbound schedulers.

-	    
Currently valid BindTypes:
-	    

-	    
-	      u
-              
-                
unbound - Schedulers will not be bound to logical
-		processors, i.e., the operating system decides where the
-		scheduler threads execute, and when to migrate them. This is
-		the default.

+            
Sets scheduler bind type.

+            
Schedulers can also be bound using flag
+              +stbt. The only
+              difference between these two flags is how the following errors
+              are handled:

+            
+              Binding of schedulers is not supported on the specific
+                platform.
+              No available CPU topology. That is, the runtime system was
+                not able to detect the CPU topology automatically, and no
+                user-defined CPU topology
+                was set.
+            
+            
If any of these errors occur when +sbt has been passed,
+              the runtime system prints an error message, and refuses to
+              start. If any of these errors occur when +stbt has been
+              passed, the runtime system silently ignores the error, and
+              start up using unbound schedulers.

+            
Valid BindTypes:

+            
+              u
+              unbound - Schedulers are not bound to logical
+                processors, that is, the operating system decides where the
+                scheduler threads execute, and when to migrate them. This is
+                the default.
               
-	      ns
-              
-                
no_spread - Schedulers with close scheduler
-		identifiers will be bound as close as possible in hardware.

+              ns
+              no_spread - Schedulers with close scheduler
+                identifiers are bound as close as possible in hardware.
               
-	      ts
-              
-                
thread_spread - Thread refers to hardware threads
-		(e.g. Intel's hyper-threads). Schedulers with low scheduler
-		identifiers, will be bound to the first hardware thread of
-		each core, then schedulers with higher scheduler identifiers
-		will be bound to the second hardware thread of each core,
-		etc.

+              ts
+              thread_spread - Thread refers to hardware threads
+                (such as Intel's hyper-threads). Schedulers with low scheduler
+                identifiers, are bound to the first hardware thread of
+                each core, then schedulers with higher scheduler identifiers
+                are bound to the second hardware thread of each core,and so on.
               
-	      ps
-              
-                
processor_spread - Schedulers will be spread like
-		thread_spread, but also over physical processor chips.

+              ps
+              processor_spread - Schedulers are spread like
+                thread_spread, but also over physical processor chips.
               
-	      s
-              
-                
spread - Schedulers will be spread as much as
-		possible.

+              s
+              spread - Schedulers are spread as much as possible.
               
-	      nnts
-              
-                
no_node_thread_spread - Like thread_spread,
-		but if multiple NUMA (Non-Uniform Memory Access) nodes exists,
-		schedulers will be spread over one NUMA node at a time,
-		i.e., all logical processors of one NUMA node will be bound
-		to schedulers in sequence.

+              nnts
+              no_node_thread_spread - Like thread_spread,
+                but if multiple Non-Uniform Memory Access (NUMA) nodes exist,
+                schedulers are spread over one NUMA node at a time,
+                that is, all logical processors of one NUMA node are bound
+                to schedulers in sequence.
               
-	      nnps
-              
-                
no_node_processor_spread - Like
-		processor_spread, but if multiple NUMA nodes exists,
-		schedulers will be spread over one NUMA node at a time, i.e.,
-		all logical processors of one NUMA node will be bound to
-		schedulers in sequence.

+              nnps
+              no_node_processor_spread - Like
+                processor_spread, but if multiple NUMA nodes exist,
+                schedulers are spread over one NUMA node at a time, that is,
+                all logical processors of one NUMA node are bound to
+                schedulers in sequence.
               
-	      tnnps
-              
-                
thread_no_node_processor_spread - A combination of
-		thread_spread, and no_node_processor_spread.
-		Schedulers will be spread over hardware threads across NUMA
-		nodes, but schedulers will only be spread over processors
-		internally in one NUMA node at a time.

+              tnnps
+              thread_no_node_processor_spread - A combination of
+                thread_spread, and no_node_processor_spread.
+                Schedulers are spread over hardware threads across NUMA
+                nodes, but schedulers are only spread over processors
+                internally in one NUMA node at a time.
               
-	      db
-              
-                
default_bind - Binds schedulers the default way.
-		Currently the default is thread_no_node_processor_spread
-		(which might change in the future).

+              db
+              default_bind - Binds schedulers the default way.
+                Defaults to thread_no_node_processor_spread
+                (which can change in the future).
               
-	    
-	    
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 automatically detected).

-            
The runtime system will by default not bind schedulers
-	       to logical processors.
-	    

-	    
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 operating system processes (as for example
-	       another Erlang runtime system) also bind threads to
-	       logical processors, there might be a performance penalty
-	       instead. In some cases this performance penalty might be
-	       severe. If this is the case, you are advised to not
-	       bind the schedulers.

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

+            
If no CPU topology is available when flag +sbt
+              is processed and BindType is any other type than
+              u, the runtime system fails to start. CPU
+              topology can be defined using flag
+              +sct. Notice
+              that flag +sct can have to be passed before flag
+              +sbt on the command line (if no CPU topology
+              has been automatically detected).

+            
The runtime system does by default not bind schedulers
+              to logical processors.

+            
+              
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 (for example
+                another Erlang runtime system) also bind threads to
+                logical processors, there can be a performance penalty
+                instead. This performance penalty can sometimes be
+                severe. If so, you are advised not to
+                bind the schedulers.

+            
             
How schedulers are bound matters. For example, in
-	       situations when there are fewer running processes than
-	       schedulers online, the runtime system tries to migrate
-	       processes to schedulers with low scheduler identifiers.
-	       The more the schedulers are spread over the hardware,
-	       the more resources will be available to the runtime
-	       system in such situations.
-	    

-	    

-	       NOTE: If a scheduler fails to bind, this
-	       will often be silently ignored. This since it isn't always
-	       possible to verify valid logical processor identifiers. If
-	       an error is reported, it will be reported to the
-	       error_logger. If you want to verify that the
-	       schedulers actually have bound as requested, call
-	       erlang:system_info(scheduler_bindings).
-	    

+              situations when there are fewer running processes than
+              schedulers online, the runtime system tries to migrate
+              processes to schedulers with low scheduler identifiers.
+              The more the schedulers are spread over the hardware,
+              the more resources are available to the runtime
+              system in such situations.

+            
+              
If a scheduler fails to bind, this is
+                often silently ignored, as it is not always
+                possible to verify valid logical processor identifiers. If
+                an error is reported, it is reported to the
+                error_logger. If you want to verify that the
+                schedulers have bound as requested, call
+                
+                erlang:system_info(scheduler_bindings).

+            
           
-	  +sbwt none|very_short|short|medium|long|very_long
-	  
-             
Set scheduler busy wait threshold. Default is medium.
-	        The threshold determines how long schedulers should busy
-		wait when running out of work before going to sleep.
-	     

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

-	  
-          +scl true|false
+          
+            +sbwt none|very_short|short|medium|long|very_long
+          
+            
Sets scheduler busy wait threshold. Defaults to medium.
+              The threshold determines how long schedulers are to busy
+              wait when running out of work before going to sleep.

+            
+              
This flag can be removed or changed at any time
+                without prior notice.

+            
+          
++scl true|false
           
-	    
Enable or disable scheduler compaction of load. By default
-	    scheduler compaction of load is enabled. When enabled, load
-	    balancing will strive for a load distribution which causes
-	    as many scheduler threads as possible to be fully loaded (i.e.,
-	    not run out of work). This is accomplished by migrating load
-	    (e.g. runnable processes) into a smaller set of schedulers
-	    when schedulers frequently run out of work. When disabled,
-	    the frequency with which schedulers run out of work will
-	    not be taken into account by the load balancing logic.
-	    
  +scl false is similar to
-	    +sub true with the difference
-	    that +sub true also will balance scheduler utilization
-	    between schedulers.
-	    

+            
Enables or disables scheduler compaction of load. By default
+              scheduler compaction of load is enabled. When enabled, load
+              balancing strives for a load distribution, which causes
+              as many scheduler threads as possible to be fully loaded (that is,
+              not run out of work). This is accomplished by migrating load
+              (for example, runnable processes) into a smaller set of schedulers
+              when schedulers frequently run out of work. When disabled,
+              the frequency with which schedulers run out of work is
+              not taken into account by the load balancing logic.

+            
+scl false is similar to
+              +sub true, but
+              +sub true also balances scheduler utilization
+              between schedulers.

           
           +sct CpuTopology
           
             
-               = integer(); when 0 =<  =< 65535]]>
+               = integer(); when 0 =<  =< 65535]]>
+              
                = -]]>
                =  | ]]>
-               = , | ]]>
+               = , |
+                ]]>
                = L]]>
-               = T | t]]>
+               = T | t]]>
+              
                = C | c]]>
-               = P | p]]>
+               = P | p]]>
+              
                = N | n]]>
-               =  | ]]>
-              : | ]]>
+               =
+                 |
+                ]]>
+              
+              : |
+                ]]>
+            
+            
Sets a user-defined CPU topology. The user-defined
+              CPU topology overrides any automatically detected
+              CPU topology. The CPU topology is used when
+              binding schedulers to logical
+              processors.

+            
Uppercase letters signify real identifiers and lowercase
+	      letters signify fake identifiers only used for description
+              of the topology. Identifiers passed as real identifiers can
+              be used by the runtime system when trying to access specific
+              hardware; if they are incorrect the behavior is
+              undefined. Faked logical CPU identifiers are not accepted,
+              as there is no point in defining the CPU topology without
+              real logical CPU identifiers. Thread, core, processor, and
+              node identifiers can be omitted. If omitted, the thread ID
+              defaults to t0, the core ID defaults to c0,
+              the processor ID defaults to p0, and the node ID is
+              left undefined. Either each logical processor must 
+              belong to only one NUMA node, or no logical
+              processors must belong to any NUMA nodes.

+            
Both increasing and decreasing ]]>s
+              are allowed.

+            
NUMA node identifiers are system wide. That is, each NUMA
+              node on the system must have a unique identifier. Processor
+              identifiers are also system wide. Core identifiers are
+              processor wide. Thread identifiers are core wide.

+            
The order of the identifier types implies the hierarchy of the
+              CPU topology. The valid orders are as follows:

+            
+              
+                
]]>,
+                  that is, thread is part of a core that is part of a processor,
+                  which is part of a NUMA node.

+              
+              
+                
]]>,
+                  that is, thread is part of a core that 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 logical processor
+              belongs to only one NUMA node. If
+              ]]> is omitted, its default position
+              is before ]]>. That is, the default is
+              processor external NUMA nodes.

+            
If a list of identifiers is used in an
+              ]]>:

+            
+              ]]> must be a list
+                of identifiers.
+              At least one other identifier type besides
+                ]]> must also have a
+                list of identifiers.
+              All lists of identifiers must produce the
+                same number of identifiers.
             
-            
Set a user defined CPU topology. The user defined
-	       CPU topology will override any automatically detected
-	       CPU topology. The CPU topology is used when
-	       binding schedulers to logical
-	       processors.
-	    

-            
Upper-case letters signify real identifiers and lower-case
-	       letters 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 ]]>s
-	        are allowed.

-	     
NUMA node identifiers are system wide. That is, each NUMA
-	        node on the system have to have a unique identifier. Processor
-		identifiers 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
-		]]>,
-		or
-		]]>.
-		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 logical processor belongs
-		to one and only one NUMA node. If ]]>
-		is left out, its default position will be before
-		]]>. That is, the default is
-		processor external NUMA nodes.
-	     

-	     
If a list of identifiers is used in an
-	        ]]>:

-             
-	       ]]> have to be a list
-	             of identifiers.
-	       At least one other identifier type apart from
-		     ]]> 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:

+            
A simple example. A single quad core processor can be
+              described as follows:

 
 % 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 processors is a little weird.
-		This in order to give a better example of identifier
-		lists:

+             {core,{logical,3}}]}]
+

A more complicated example with two quad core + processors, each processor in its own NUMA node. + The ordering of logical processors is a bit weird. + This 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).
@@ -1221,239 +1203,247 @@
  {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 - different logical CPUs. An example, with two Erlang - runtime systems on a quad core machine:

+ {core,{logical,5}}]}]}] +

As long as real identifiers are correct, it is OK + to pass a CPU topology that is not a correct + description of the CPU topology. When used with + care this can be very useful. This + 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 number of schedulers used and + manipulate the CPU topology so that they bind to + different 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_info(cpu_topology).

+% 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.

+

Notice 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_info(cpu_topology).

+secio true|false -

Enable or disable eager check I/O scheduling. The default - is currently true. The default was changed from false - to true as of erts version 7.0. The behaviour before this - flag was introduced corresponds to +secio false.

-

The flag effects when schedulers will check for I/O - operations possible to execute, and when such I/O operations - will execute. As the name of the parameter implies, - schedulers will be more eager to check for I/O when - true is passed. This however also implies that - execution of outstanding I/O operation will not be - prioritized to the same extent as when false is - passed.

-

erlang:system_info(eager_check_io) - returns the value of this parameter used when starting the VM.

+

Enables or disables eager check I/O scheduling. Defaults + to true. The default was changed from false + as from ERTS 7.0. The behavior before this + flag was introduced corresponds to +secio false.

+

The flag effects when schedulers will check for I/O + operations possible to execute, and when such I/O operations + will execute. As the parameter name implies, + schedulers are more eager to check for I/O when + true is passed. This, however, also implies that + execution of outstanding I/O operation is not + prioritized to the same extent as when false is + passed.

+

+ erlang:system_info(eager_check_io) + returns the value of this parameter used when starting + the virtual machine.

 +sfwi Interval -

Set scheduler forced wakeup interval. All run queues will - be scanned each Interval milliseconds. While there are - sleeping schedulers in the system, one scheduler will be woken - for each non-empty run queue found. An Interval of zero - disables this feature, which also is the default. -

-

This feature has been introduced as a temporary workaround - for long-executing native code, and native code that does not - bump reductions properly in OTP. When these bugs have be fixed - the +sfwi flag will be removed. -

- +

Sets scheduler-forced wakeup interval. All run queues are + scanned each Interval milliseconds. While there are + sleeping schedulers in the system, one scheduler is woken + for each non-empty run queue found. Interval default + to 0, meaning this feature is disabled.

+ +

This feature has been introduced as a temporary workaround + for long-executing native code, and native code that does not + bump reductions properly in OTP. When these bugs have be fixed, + this flag will be removed.

+ + + +spp Bool + +

Sets default scheduler hint for port parallelism. If set to + true, the virtual machine schedules port tasks when it + improves parallelism in the system. If set to false, the + virtual machine tries to perform port tasks immediately, + improving latency at the expense of parallelism. Default to + false. The default used can be inspected in runtime by + calling + erlang:system_info(port_parallelism). + The default can be overridden on port creation by passing option + + parallelism to + + erlang:open_port/2

. + + + + +

Suggested stack size, in kilowords, for scheduler threads. + Valid range is 4-8192 kilowords. The default stack size is + OS-dependent.

+ +stbt BindType -

Try to set scheduler bind type. The same as the - +sbt flag with the exception of - how some errors are handled. For more information, see the - documentation of the +sbt flag. -

- +

Tries to set the scheduler bind type. The same as flag + +sbt except + how some errors are handled. For more information, see + +sbt.

+ +sub true|false -

Enable or disable - scheduler - utilization balancing of load. By default scheduler - utilization balancing is disabled and instead scheduler - compaction of load is enabled which will strive for a load - distribution which causes as many scheduler threads as possible - to be fully loaded (i.e., not run out of work). When scheduler - utilization balancing is enabled the system will instead try to - balance scheduler utilization between schedulers. That is, - strive for equal scheduler utilization on all schedulers. -
   +sub true is only supported on - systems where the runtime system detects and uses a monotonically - increasing high resolution clock. On other systems, the runtime - system will fail to start. -
   +sub true implies - +scl false. The difference - between +sub true and +scl false is that - +scl false will not try to balance the scheduler - utilization. -

+

Enables or disables + + scheduler utilization balancing of load. By default + scheduler utilization balancing is disabled and instead scheduler + compaction of load is enabled, which strives for a load + distribution that causes as many scheduler threads as possible + to be fully loaded (that is, not run out of work). When scheduler + utilization balancing is enabled, the system instead tries to + balance scheduler utilization between schedulers. That is, + strive for equal scheduler utilization on all schedulers.

+

+sub true is only supported on systems where the runtime + system detects and uses a monotonically increasing high-resolution + clock. On other systems, the runtime system fails to start.

+

+sub true implies + +scl false. The difference between + +sub true and +scl false is that +scl false + does not try to balance the scheduler utilization.

 - +swct very_eager|eager|medium|lazy|very_lazy - -

- Set scheduler wake cleanup threshold. Default is medium. - This flag controls how eager schedulers should be requesting - wake up due to certain cleanup operations. When a lazy setting - is used, more outstanding cleanup operations can be left undone - while a scheduler is idling. When an eager setting is used, - schedulers will more frequently be woken, potentially increasing - CPU-utilization. -

-

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

- - +sws default|legacy - -

- Set scheduler wakeup strategy. Default strategy changed in erts-5.10/OTP-R16A. This strategy was previously known as proposal in OTP-R15. The legacy strategy was used as default from R13 up to and including R15. -

-

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

- - +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 multiple schedulers faster, but work will - more easily bounce between schedulers. -

-

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

- - +spp Bool + + +swct very_eager|eager|medium|lazy|very_lazy -

Set default scheduler hint for port parallelism. If set to - true, the VM will schedule port tasks when doing so will - improve parallelism in the system. If set to false, the VM - will try to perform port tasks immediately, improving latency at the - expense of parallelism. If this flag has not been passed, the - default scheduler hint for port parallelism is currently - false. The default used can be inspected in runtime by - calling erlang:system_info(port_parallelism). - The default can be overriden on port creation by passing the - parallelism - option to open_port/2

. - - - -

Suggested stack size, in kilowords, for scheduler threads. - Valid range is 4-8192 kilowords. The default stack size - is OS dependent.

- +

Sets scheduler wake cleanup threshold. Defaults to medium. + Controls how eager schedulers are to be requesting + wakeup because of certain cleanup operations. When a lazy setting + is used, more outstanding cleanup operations can be left undone + while a scheduler is idling. When an eager setting is used, + schedulers are more frequently woken, potentially increasing + CPU-utilization.

+ +

This flag can be removed or changed at any time without prior + notice.

+ + + +sws default|legacy + +

Sets scheduler wakeup strategy. Default strategy changed in + ERTS 5.10 (Erlang/OTP R16A). This strategy was known as + proposal in Erlang/OTP R15. The legacy strategy + was used as default from R13 up to and including R15.

+ +

This flag can be removed or changed at any time without prior + notice.

+ + + + +swt very_low|low|medium|high|very_high + +

Sets scheduler wakeup threshold. Defaults to medium. + The threshold determines when to wake up sleeping schedulers + when more work than can be handled by currently awake schedulers + exists. A low threshold causes earlier wakeups, and a high + threshold causes later wakeups. Early wakeups distribute work + over multiple schedulers faster, but work does more easily bounce + between schedulers.

+ +

This flag can be removed or changed at any time without prior + notice.

+ + -

Set the maximum number of atoms the VM can handle. Default is 1048576.

+

Sets the maximum number of atoms the virtual machine can handle. + Defaults to 1,048,576.

 -

Enables modified timing and sets the modified timing level. - Currently 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:

+

Enables modified timing and sets the modified timing level. Valid + range is 0-9. The timing of the runtime system is changed. A high + level usually means a greater change than a low level. Changing the + timing can be very useful for finding timing-related bugs.

+

Modified timing affects the following:

Process spawning - -

A process calling , , - , or 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.

+ A process calling , + , , + or is scheduled out immediately + after completing the call. When higher modified timing levels are + used, the caller also sleeps for a while after it is scheduled out. Context reductions - The amount of reductions a process is a allowed to - use before being scheduled out is increased or reduced. + The number of reductions a process is allowed to use before it + is scheduled out is increased or reduced. + Input reductions - The amount of reductions performed before checking I/O - is increased or reduced. + The number 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 and - trace messages will be lost when tracing on the spawn BIFs. This - flag may be removed or changed at any time without prior notice.

- - - -

Makes the emulator print out its version number.

+ +

Performance suffers when modified timing is enabled. This flag is + only intended for testing and debugging.

+

and + trace messages are lost when tracing on the spawn BIFs.

+

This flag can be removed or changed at any time without prior + notice.

+

Verbose.

 + + +

Makes the emulator print its version number.

+ -

Sets the mapping of warning messages for . - Messages sent to the error logger using one of the warning - routines can be mapped either to errors (), - warnings (), or info reports - (). The default is warnings. +

Sets the mapping of warning messages for + . Messages sent to the error logger + using one of the warning routines can be mapped to errors + (), warnings (), or + information reports (). Defaults to warnings. The current mapping can be retrieved using - . See - error_logger(3) - for further information.

+ . For more information, + see + error_logger:warning_map/0 in Kernel.

 -

Miscellaneous flags.

+

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 outgoing messages over the distribution. When the - buffer limit has been reached, sending processes will be - suspended until the buffer size has shrunk. The buffer - limit is per distribution channel. A higher limit will - give lower latency and higher throughput at the expense - of higher memory usage.

+

Sets the distribution buffer busy limit + ( + dist_buf_busy_limit) + in kilobytes. Valid range is 1-2097151. Defaults to 1024.

+

A larger buffer limit allows processes to buffer + more outgoing messages over the distribution. When the + buffer limit has been reached, sending processes will be + suspended until the buffer size has shrunk. The buffer + limit is per distribution channel. A higher limit + gives lower latency and higher throughput at the expense + of higher memory use.

 +zdntgc time -

Set the delayed node table garbage collection time - (delayed_node_table_gc) - in seconds. Valid values are either infinity or - an integer in the range [0-100000000]. Default is 60.

-

Node table entries that are not referred will linger - in the table for at least the amount of time that this - parameter determines. The lingering prevents repeated - deletions and insertions in the tables from occurring. -

+

Sets the delayed node table garbage collection time + ( + delayed_node_table_gc) + in seconds. Valid values are either infinity or + an integer in the range 0-100000000. Defaults to 60.

+

Node table entries that are not referred linger + in the table for at least the amount of time that this + parameter determines. The lingering prevents repeated + deletions and insertions in the tables from occurring.

 @@ -1462,104 +1452,95 @@
- Environment variables + Environment Variables

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 variable is not set, the name of the crash dump file will - be in the current directory.

+ variable is the filename of the crash dump file. + If the variable is not set, the name of the crash dump file is + in the current directory.

 -

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.

+

Unix systems: If the emulator needs to write a crash dump, + it uses the value of this variable to set the nice value + for the process, thus lowering its priority. Valid range is + 1-39 (higher values are replaced with 39). The highest + value, 39, gives the process the lowest priority.

 -

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 - terminated by a SIGALRM signal.

- -

If the environment variable is not set or it is set to zero seconds, , - the runtime system will not even attempt to write the crash dump file. It will just terminate. -

-

If the environment variable is set to negative valie, e.g. , - the runtime system will wait indefinitely for the crash dump file to be written. -

-

This environment variable is used in conjuction with - heart if heart is running: -

- - -

- Suppresses the writing a crash dump file entirely, - thus rebooting the runtime system immediately. - This is the same as not setting the environment variable. -

- - -

Setting the environment variable to a negative value will cause the - termination of the runtime system to wait until the crash dump file - has been completly written. -

- - -

- Will wait for S seconds to complete the crash dump file and - then terminate the runtime system. -

- - +

Unix systems: This variable gives the number of seconds + that the emulator is allowed to spend writing a crash dump. When the + given number of seconds have elapsed, the emulator is terminated by a + SIGALRM signal.

+

If the variable is not set or set to 0 seconds + (), the runtime system does + not even attempt to write the crash dump file. It only terminates.

+

If the variable is set to negative value, such as + , the runtime system + waits indefinitely for the crash dump file to be written.

+

This variable is used with + kernel:heart if heart is running:

+ + + Suppresses the writing a crash dump file entirely, thus + rebooting the runtime system immediately. This is the same as not + setting the environment variable. + + + Setting the environment variable to a negative value causes the + termination of the runtime system to wait until the crash dump file + has been completly written. + + + Waits for S seconds to complete the crash dump file and + then terminates the runtime system. + + -

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

-

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

- - and - -

The content of these environment variables will be added to the - end of the command line for .

-

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

+

The content of this variable is added to the beginning of the + command line for .

+

Flag is treated in a special way. Its + scope ends at the end of the environment variable content. Arguments + following an flag are moved on the command + line into section , that is, the end of the + command line following an flag.

+ + and + + +

The content of these variables are added to the end of the command + line for .

+

Flag is treated in a special way. Its + scope ends at the end of the environment variable content. Arguments + following an flag are moved on the command + line into section , that is, the end of the + command line following an flag.

 -

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(3).

+

Contains a list of additional library directories that the code + server searches for applications and adds to the code path; see + kernel:code(3).

 -

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 implicitly added to the list if it - has not been specified).

+

Can be set to a comma-separated list of IP addresses, in which case + the epmd daemon listens only + on the specified address(es) and on the loopback address (which is + implicitly added to the list if it has not been specified).

 -

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 +

Can contain the port number to use when communicating with + epmd. The default port works + fine in most cases. A different port can be specified to allow nodes of independent clusters to co-exist on the same host. - All nodes in a cluster must use the same epmd port number.

+ All nodes in a cluster must use the same epmd port number.
@@ -1567,59 +1548,64 @@
Configuration -

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

+

The standard Erlang/OTP system can be reconfigured to change the default + behavior on startup.

- 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:

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

+ The .erlang startup 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:

- - 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(3) - for further information.

- +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 that 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:

+ + + erl + +

If the contents of .erlang are changed and a private version + of user_default is defined, the Erlang/OTP environment can be + customized. More powerful changes can be made by supplying + command-line arguments in the startup script erl. For more + information, see init(3).

+
-
- SEE ALSO -

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

+
+ See Also +

epmd(1), + erl_prim_loader(3), + erts_alloc(3), + init(3), + + kernel:application(3), + kernel:auth(3), + kernel:code(3), + + kernel:erl_boot_server(3), + kernel:heart(3), + kernel:net_kernel(3), + tools:make(3)

-- cgit v1.2.3