Use this option when receiving binaries from an untrusted source.

When enabled, it prevents decoding data that may be used to attack the Erlang system. In the event of receiving unsafe data, decoding fails with a badarg error.

Currently, this prevents creation of new atoms directly, creation of new atoms indirectly (as they are embedded in certain structures like pids, refs, funs, etc.), and creation of new external function references. None of those resources are currently garbage collected, so unchecked creation of them can exhaust available memory.

No packet handling is done. Entire binary is returned unless it is empty.

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

A packet is a line terminated with newline. The newline character is included in the returned packet unless the line was truncated according to the option line_length.

The header is not stripped off.

The meanings of the packet types are as follows:

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

Recognized request methods and header fields are returned as atoms. Others are returned as strings.

The protocol type http should only be used for the first line when a HttpRequest or a HttpResponse is expected. The following calls should use httph to get HttpHeader's until http_eoh is returned that marks the end of the headers and the beginning of any following message body.

The variants http_bin and httph_bin will return strings (HttpString) as binaries instead of lists.

Sets the max allowed size of the packet body. If the packet header indicates that the length of the packet is longer than the max allowed length, the packet is considered invalid. Default is 0 which means no size limit.

For packet type line, truncate lines longer than the indicated length.

Option line_length also applies to http* packet types as an alias for option packet_size in the case when packet_size itself is not set. This usage is only intended for backward compatibility.

Remove (one) {_, MonitorRef, _, _, _} message, if there is one, from the caller's message queue after monitoring has been stopped.

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

The returned value is one of the following:

If the info option is combined with the flush option, false will be returned if a flush was needed; otherwise, true.

The second element of the tuple is a string (list of characters) representing the filename of the source file of the function.

The second element of the tuple is the line number (an integer greater than zero) in the source file where the exception occurred or the function was called.

The object code in Binary has an incorrect format.

Binary contains a module which cannot be loaded because old code for this module already exists.

The object code contains code for another module than Module

The OS failed to load the NIF library.

The library did not fulfil the requirements as a NIF library of the calling module.

The corresponding library callback was not successful.

The call to load_nif/2 was made from the old code of a module that has been upgraded. This is not allowed.

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

The total amount of memory currently allocated by the Erlang processes.

The total amount of memory currently used by the Erlang processes.

This memory is part of the memory presented as processes memory.

The total amount of memory currently allocated by the emulator that is not directly related to any Erlang process.

Memory presented as processes is not included in this memory.

The total amount of memory currently allocated for atoms.

This memory is part of the memory presented as system memory.

The total amount of memory currently used for atoms.

This memory is part of the memory presented as atom memory.

The total amount of memory currently allocated for binaries.

This memory is part of the memory presented as system memory.

The total amount of memory currently allocated for Erlang code.

This memory is part of the memory presented as system memory.

The total amount of memory currently allocated for ets tables.

This memory is part of the memory presented as system memory.

The maximum total amount of memory allocated since the emulator was started.

This tuple is only present when the emulator is run with instrumentation.

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

Only on 64-bit halfword emulator.

The total amount of memory allocated in low memory areas that are restricted to less than 4 Gb even though the system may have more physical memory.

May be removed in future releases of halfword emulator.

The pid of the process to monitor.

A tuple consisting of a registered name of a process and a node name. The process residing on the node Node with the registered name RegName will be monitored.

The process locally registered as RegName will be monitored.

A reference to the monitored object:

Either the exit reason of the process, noproc (non-existing process), or noconnection (no connection to Node).

Nodes connected to this node through normal connections.

Nodes connected to this node through hidden connections.

All nodes connected to this node.

This node.

Nodes which are known to this node, i.e., connected, previously connected, etc.

Starts an external program. Command is the name of the external program which will be run. Command runs outside the Erlang work space unless an Erlang driver with the name Command is found. If found, that driver will be started. A driver runs in the Erlang workspace, which means that it is linked with the Erlang runtime system.

When starting external programs on Solaris, the system call vfork is used in preference to fork for performance reasons, although it has a history of being less robust. If there are problems with using vfork, setting the environment variable ERL_NO_VFORK to any value will cause fork to be used instead.

For external programs, the PATH is searched (or an equivalent method is used to find programs, depending on operating system). This is done by invoking the shell on certain platforms. The first space separated token of the command will be considered as the name of the executable (or driver). This (among other things) makes this option unsuitable for running programs having spaces in file or directory names. Use {spawn_executable, Command} instead if spaces in executable file names is desired.

Works like {spawn, Command}, but demands the first (space separated) token of the command to be the name of a loaded driver. If no driver with that name is loaded, a badarg error is raised.

Works like {spawn, Command}, but only runs external executables. The Command in its whole is used as the name of the executable, including any spaces. If arguments are to be passed, the args and arg0 PortSettings can be used.

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

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

The name of the executable as well as the arguments given in args and arg0 is subject to Unicode file name translation if the system is running in Unicode file name mode. To avoid translation or force i.e. UTF-8, supply the executable and/or arguments as a binary in the correct encoding. See the file module, the file:native_name_encoding/0 function and the stdlib users guide for details.

If the Command cannot be run, an error exception, with the posix error code as the reason, is raised. The error reason may differ between operating systems. Typically the error enoent is raised when one tries to run a program that is not found and eaccess is raised when the given file is not executable.

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

Messages are preceded by their length, sent in N bytes, with the most significant byte first. Valid values for N are 1, 2, or 4.

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

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

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

The {packet, N} and {line, L} settings are mutually exclusive.

This is only valid for {spawn, Command} and {spawn_executable, Command}. The external program starts using Dir as its working directory. Dir must be a string. Not available on VxWorks.

This is only valid for {spawn, Command} and {spawn_executable, Command}. The environment of the started process is extended using the environment specifications in Env.

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

This option is only valid for {spawn_executable, Command} and specifies arguments to the executable. Each argument is given as a separate string and (on Unix) eventually ends up as one element each in the argument vector. On other platforms, similar behavior is mimicked.

The arguments are not expanded by the shell prior to being supplied to the executable, most notably this means that file wildcard expansion will not happen. Use filelib:wildcard/1 to expand wildcards for the arguments. Note that even if the program is a Unix shell script, meaning that the shell will ultimately be invoked, wildcard expansion will not happen and the script will be provided with the untouched arguments. On Windows®, wildcard expansion is always up to the program itself, why this isn't an issue.

Note also that the actual executable name (a.k.a. argv[0]) should not be given in this list. The proper executable name will automatically be used as argv[0] where applicable.

When the Erlang VM is running in Unicode file name mode, the arguments can contain any Unicode characters and will be translated into whatever is appropriate on the underlying OS, which means UTF-8 for all platforms except Windows, which has other (more transparent) ways of dealing with Unicode arguments to programs. To avoid Unicode translation of arguments, they can be supplied as binaries in whatever encoding is deemed appropriate.

If one, for any reason, wants to explicitly set the program name in the argument vector, the arg0 option can be used.

This option is only valid for {spawn_executable, Command} and explicitly specifies the program name argument when running an executable. This might in some circumstances, on some operating systems, be desirable. How the program responds to this is highly system dependent and no specific effect is guaranteed.

The unicode file name translation rules of the args option apply to this option as well.

This is only valid for {spawn, Command} where Command refers to an external program, and for {spawn_executable, Command}.

When the external process connected to the port exits, a message of the form {Port,{exit_status,Status}} is sent to the connected process, where Status is the exit status of the external process. If the program aborts, on Unix the same convention is used as the shells do (i.e., 128+signal).

If the eof option has been given as well, the eof message and the exit_status message appear in an unspecified order.

If the port program closes its stdout without exiting, the exit_status option will not work.

This is only valid for {spawn, Command} and {spawn_executable, Command}. It allows the standard input and output (file descriptors 0 and 1) of the spawned (UNIX) process for communication with Erlang.

The opposite of use_stdio. Uses file descriptors 3 and 4 for communication with Erlang.

Affects ports to external programs. The executed program gets its standard error file redirected to its standard output file. stderr_to_stdout and nouse_stdio are mutually exclusive.

Affects ports to external programs on Windows® only. The standard input and standard output handles of the port program will, if this option is supplied, be opened with the flag FILE_FLAG_OVERLAPPED, so that the port program can (and has to) do overlapped I/O on its standard handles. This is not normally the case for simple port programs, but an option of value for the experienced Windows programmer. On all other platforms, this option is silently discarded.

The port can only be used for input.

The port can only be used for output.

All IO from the port are binary data objects as opposed to lists of bytes.

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

When running on Windows, suppress creation of a new console window when spawning the port program. (This option has no effect on other platforms.)

Bad input arguments to open_port.

All available ports in the Erlang emulator are in use.

There was not enough memory to create the port.

There are no more available operating system processes.

The external command given was too long.

There are no more available file descriptors (for the operating system process that the Erlang emulator runs in).

The file table is full (for the entire operating system).

The Command given in {spawn_executable, Command} does not point out an executable file.

The Command given in {spawn_executable, Command} does not point out an existing file.

RegName (an atom) is the registered name of the port. If the port has no registered name, this tuple is not present in the list.

Index (an integer) is the internal index of the port. This index may be used to separate ports.

Pid is the process connected to the port.

Pids is a list of pids to which processes the port is linked.

String is the command name set by open_port.

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

Bytes is the total number of bytes written to the port.

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

See also exit/2.

This is used by a process to redefine the error handler for undefined function calls and undefined registered processes. Inexperienced users should not use this flag since code auto-loading is dependent on the correct operation of the error handling module.

This changes the minimum heap size for the calling process.

This changes the minimum binary virtual heap size for the calling process.

This sets the process priority. Level is an atom. There are currently four priority levels: low, normal, high, and max. The default priority level is normal. NOTE: The max priority level is reserved for internal use in the Erlang runtime system, and should not be used by others.

Internally in each priority level processes are scheduled in a round robin fashion.

Execution of processes on priority normal and priority low will be interleaved. Processes on priority low will be selected for execution less frequently than processes on priority normal.

When there are runnable processes on priority high no processes on priority low, or normal will be selected for execution. Note, however, that this does not mean that no processes on priority low, or normal will be able to run when there are processes on priority high running. On the runtime system with SMP support there might be more processes running in parallel than processes on priority high, i.e., a low, and a high priority process might execute at the same time.

When there are runnable processes on priority max no processes on priority low, normal, or high will be selected for execution. As with the high priority, processes on lower priorities might execute in parallel with processes on priority max.

Scheduling is preemptive. Regardless of priority, a process is preempted when it has consumed more than a certain amount of reductions since the last time it was selected for execution.

NOTE: You should not depend on the scheduling to remain exactly as it is today. Scheduling, at least on the runtime system with SMP support, is very likely to be modified in the future in order to better utilize available processor cores.

There is currently no automatic mechanism for avoiding priority inversion, such as priority inheritance, or priority ceilings. When using priorities you have to take this into account and handle such scenarios by yourself.

Making calls from a high priority process into code that you don't have control over may cause the high priority process to wait for a processes with lower priority, i.e., effectively decreasing the priority of the high priority process during the call. Even if this isn't the case with one version of the code that you don't have under your control, it might be the case in a future version of it. This might, for example, happen if a high priority process triggers code loading, since the code server runs on priority normal.

Other priorities than normal are normally not needed. When other priorities are used, they need to be used with care, especially the high priority must be used with care. A process on high priority should only perform work for short periods of time. Busy looping for long periods of time in a high priority process will most likely cause problems, since there are important servers in OTP running on priority normal.

N must be an integer in the interval 0..10000. If N > 0, call saving is made active for the process, which means that information about the N most recent global function calls, BIF calls, sends and receives made by the process are saved in a list, which can be retrieved with process_info(Pid, last_calls). A global function call is one in which the module of the function is explicitly mentioned. Only a fixed amount of information is saved: a tuple {Module, Function, Arity} for function calls, and the mere atoms send, 'receive' and timeout for sends and receives ('receive' when a message is received and timeout when a receive times out). If N = 0, call saving is disabled for the process, which is the default. Whenever the size of the call saving list is set, its contents are reset.

Set or clear the sensitive flag for the current process. When a process has been marked as sensitive by calling process_flag(sensitive, true), features in the run-time system that can be used for examining the data and/or inner working of the process are silently disabled.

Features that are disabled include (but are not limited to) the following:

Tracing: Trace flags can still be set for the process, but no trace messages of any kind will be generated. (If the sensitive flag is turned off, trace messages will again be generated if there are any trace flags set.)

Sequential tracing: The sequential trace token will be propagated as usual, but no sequential trace messages will be generated.

process_info/1,2 cannot be used to read out the message queue or the process dictionary (both will be returned as empty lists).

Stack back-traces cannot be displayed for the process.

In crash dumps, the stack, messages, and the process dictionary will be omitted.

If {save_calls,N} has been set for the process, no function calls will be saved to the call saving list. (The call saving list will not be cleared; furthermore, send, receive, and timeout events will still be added to the list.)

The binary Bin contains the same information as the output from erlang:process_display(Pid, backtrace). Use binary_to_list/1 to obtain the string of characters from the binary.

BinInfo is a list containing miscellaneous information about binaries currently being referred to by this process. This InfoTuple may be changed or removed without prior notice.

CatchLevel is the number of currently active catches in this process. This InfoTuple may be changed or removed without prior notice.

Module, Function, Arity is the current function call of the process.

Module, Function, Arity is the current function call of the process. Location is a list of two-tuples that describes the location in the source code.

Return the current call stack back-trace (stacktrace) of the process. The stack has the same format as returned by erlang:get_stacktrace/0.

Dictionary is the dictionary of the process.

Module is the error handler module used by the process (for undefined function calls, for example).

GCInfo is a list which contains miscellaneous information about garbage collection for this process. The content of GCInfo may be changed without prior notice.

GroupLeader is group leader for the IO of the process.

Size is the size in words of youngest heap generation of the process. This generation currently include the stack of the process. This information is highly implementation dependent, and may change if the implementation change.

Module, Function, Arity is the initial function call with which the process was spawned.

Pids is a list of pids, with processes to which the process has a link.

The value is false if call saving is not active for the process (see process_flag/3). If call saving is active, a list is returned, in which the last element is the most recent called.

Size is the size in bytes of the process. This includes call stack, heap and internal structures.

BinInfo is a list containing miscellaneous information about binaries currently being referred to by the message area. This InfoTuple is only valid on an emulator using the hybrid heap type. This InfoTuple may be changed or removed without prior notice.

MessageQueueLen is the number of messages currently in the message queue of the process. This is the length of the list MessageQueue returned as the info item messages (see below).

MessageQueue is a list of the messages to the process, which have not yet been processed.

MinHeapSize is the minimum heap size for the process.

MinBinVHeapSize is the minimum binary virtual heap size for the process.

A list of pids that are monitoring the process (with monitor/2).

A list of monitors (started by monitor/2) that are active for the process. For a local process monitor or a remote process monitor by pid, the list item is {process, Pid}, and for a remote process monitor by name, the list item is {process, {RegName, Node}}.

Level is the current priority level for the process. For more information on priorities see process_flag(priority, Level).

Number is the number of reductions executed by the process.

Atom is the registered name of the process. If the process has no registered name, this tuple is not present in the list.

SequentialTraceToken the sequential trace token for the process. This InfoTuple may be changed or removed without prior notice.

Size is the stack size of the process in words.

Status is the status of the process. Status is exiting, garbage_collecting, waiting (for a message), running, runnable (ready to run, but another process is running), or suspended (suspended on a "busy" port or by the erlang:suspend_process/[1,2] BIF).

SuspendeeList is a list of {Suspendee, ActiveSuspendCount, OutstandingSuspendCount} tuples. Suspendee is the pid of a process that have been or is to be suspended by the process identified by Pid via the erlang:suspend_process/2 BIF, or the erlang:suspend_process/1 BIF. ActiveSuspendCount is the number of times the Suspendee has been suspended by Pid. OutstandingSuspendCount is the number of not yet completed suspend requests sent by Pid. That is, if ActiveSuspendCount /= 0, Suspendee is currently in the suspended state, and if OutstandingSuspendCount /= 0 the asynchronous option of erlang:suspend_process/2 has been used and the suspendee has not yet been suspended by Pid. Note that the ActiveSuspendCount and OutstandingSuspendCount are not the total suspend count on Suspendee, only the parts contributed by Pid.

Size is the total size in words of all heap fragments of the process. This currently include the stack of the process.

InternalTraceFlags is an integer representing internal trace flag for this process. This InfoTuple may be changed or removed without prior notice.

Boolean is true if the process is trapping exits, otherwise it is false.

If the sender would have to be suspended to do the send, nosuspend is returned instead.

If the destination node would have to be auto-connected before doing the send, noconnect is returned instead.

Returns {ContextSwitches, 0}, where ContextSwitches is the total number of context switches since the system started.

Returns {Total_Exact_Reductions, Exact_Reductions_Since_Last_Call}.

NOTE:statistics(exact_reductions) is a more expensive operation than statistics(reductions) especially on an Erlang machine with SMP support.

Returns {Number_of_GCs, Words_Reclaimed, 0}. This information may not be valid for all implementations.

Returns {{input, Input}, {output, Output}}, where Input is the total number of bytes received through ports, and Output is the total number of bytes output to ports.

Returns {Total_Reductions, Reductions_Since_Last_Call}.

NOTE: From erts version 5.5 (OTP release R11B) this value does not include reductions performed in current time slices of currently scheduled processes. If an exact value is wanted, use statistics(exact_reductions).

Returns the length of the run queue, that is, the number of processes that are ready to run.

Returns {Total_Run_Time, Time_Since_Last_Call}. Note that the run-time is the sum of the run-time for all threads in the Erlang run-time system and may therefore be greater than the wall-clock time.

Returns a list of tuples with {SchedulerId, ActiveTime, TotalTime}], where SchedulerId is an integer id of the scheduler, ActiveTime is the duration the scheduler has been busy, TotalTime is the total time duration since scheduler_wall_time activation. The time unit is not defined and may be subject to change between releases, operating systems and system restarts. scheduler_wall_time should only be used to calculate relative values for scheduler-utilization. ActiveTime can never exceed TotalTime.

The definition of a busy scheduler is when it is not idle or not scheduling (selecting) a process or port, meaning; executing process code, executing linked-in-driver or NIF code, executing built-in-functions or any other runtime handling, garbage collecting or handling any other memory management.

Returns undefined if the system flag scheduler_wall_time is turned off.

The list of scheduler information is unsorted and may come in different order between calls.

Using scheduler_wall_time to calculate scheduler utilization.

> erlang:system_flag(scheduler_wall_time, true).
false
> Ts0 = lists:sort(erlang:statistics(scheduler_wall_time)), ok.
ok

Some time later we will take another snapshot and calculate scheduler-utilization per scheduler.

> Ts1 = lists:sort(erlang:statistics(scheduler_wall_time)), ok.
ok
> lists:map(fun({{I, A0, T0}, {I, A1, T1}}) ->
	{I, (A1 - A0)/(T1 - T0)} end, lists:zip(Ts0,Ts1)).
[{1,0.9743474730177548},
 {2,0.9744843782751444},
 {3,0.9995902361669045},
 {4,0.9738012596572161},
 {5,0.9717956667018103},
 {6,0.9739235846420741},
 {7,0.973237033077876},
 {8,0.9741297293248656}]

Using the same snapshots to calculate a total scheduler-utilization.

> {A, T} = lists:foldl(fun({{_, A0, T0}, {_, A1, T1}}, {Ai,Ti}) ->
	{Ai + (A1 - A0), Ti + (T1 - T0)} end, {0, 0}, lists:zip(Ts0,Ts1)), A/T.
0.9769136803764825

Returns {Total_Wallclock_Time, Wallclock_Time_Since_Last_Call}. wall_clock can be used in the same manner as runtime, except that real time is measured as opposed to runtime or CPU time.

Sets the maximum depth of call stack back-traces in the exit reason element of 'EXIT' tuples.

NOTE: This argument is deprecated and scheduled for removal in erts-5.10/OTP-R16. Instead of using this argument you are advised to use the erl command line argument +sct. When this argument has been removed a final CPU topology to use will be determined at emulator boot time.

Sets the user defined CpuTopology. The user defined CPU topology will override any automatically detected CPU topology. By passing undefined as CpuTopology the system will revert back to the CPU topology automatically detected. The returned value equals the value returned from erlang:system_info(cpu_topology) before the change was made.

The CPU topology is used when binding schedulers to logical processors. If schedulers are already bound when the CPU topology is changed, the schedulers will be sent a request to rebind according to the new CPU topology.

The user defined CPU topology can also be set by passing the +sct command line argument to erl.

For information on the CpuTopology type and more, see the documentation of erlang:system_info(cpu_topology), and the erl +sct and +sbt command line flags.

Number is a non-negative integer which indicates how many times generational garbage collections can be done without forcing a fullsweep collection. The value applies to new processes; processes already running are not affected.

In low-memory systems (especially without virtual memory), setting the value to 0 can help to conserve memory.

An alternative way to set this value is through the (operating system) environment variable ERL_FULLSWEEP_AFTER.

Sets the default minimum heap size for processes. The size is given in words. The new min_heap_size only effects processes spawned after the change of min_heap_size has been made. The min_heap_size can be set for individual processes by use of spawn_opt/N or process_flag/2.

Sets the default minimum binary virtual heap size for processes. The size is given in words. The new min_bin_vhheap_size only effects processes spawned after the change of min_bin_vhheap_size has been made. The min_bin_vheap_size can be set for individual processes by use of spawn_opt/N or process_flag/2.

BlockState = block | unblock

If multi-scheduling is enabled, more than one scheduler thread is used by the emulator. Multi-scheduling can be blocked. When multi-scheduling has been blocked, only one scheduler thread will schedule Erlang processes.

If BlockState =:= block, multi-scheduling will be blocked. If BlockState =:= unblock and no-one else is blocking multi-scheduling and this process has only blocked one time, multi-scheduling will be unblocked. One process can block multi-scheduling multiple times. If a process has blocked multiple times, it has to unblock exactly as many times as it has blocked before it has released its multi-scheduling block. If a process that has blocked multi-scheduling exits, it will release its blocking of multi-scheduling.

The return values are disabled, blocked, or enabled. The returned value describes the state just after the call to erlang:system_flag(multi_scheduling, BlockState) has been made. The return values are described in the documentation of erlang:system_info(multi_scheduling).

NOTE: Blocking of multi-scheduling should normally not be needed. If you feel that you need to block multi-scheduling, think through the problem at least a couple of times again. Blocking multi-scheduling should only be used as a last resort since it will most likely be a very inefficient way to solve the problem.

See also erlang:system_info(multi_scheduling), erlang:system_info(multi_scheduling_blockers), and erlang:system_info(schedulers).

NOTE: This argument is deprecated and scheduled for removal in erts-5.10/OTP-R16. Instead of using this argument you are advised to use the erl command line argument +sbt. When this argument has been removed a final scheduler bind type to use will be determined at emulator boot time.

Controls if and how schedulers are bound to logical processors.

When erlang:system_flag(scheduler_bind_type, How) is called, an asynchronous signal is sent to all schedulers online which causes them to try to bind or unbind as requested. 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).

Schedulers can currently only be bound on newer Linux, Solaris, FreeBSD, and Windows systems, but more systems will be supported in the future.

In order for the runtime system to be able to bind schedulers, the CPU topology needs to be known. If the runtime system fails to automatically detect the CPU topology, it can be defined. For more information on how to define the CPU topology, see the erl +sct command line flag.

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.

Schedulers can be bound in different ways. The How argument determines how schedulers are bound. How can currently be one of:

The value returned equals How before the scheduler_bind_type flag was changed.

Failure:

The scheduler bind type can also be set by passing the +sbt command line argument to erl.

For more information, see erlang:system_info(scheduler_bind_type), erlang:system_info(scheduler_bindings), the erl +sbt and +sct command line flags.

Turns on/off scheduler wall time measurements.

For more information see, erlang:statistics(scheduler_wall_time).

Sets the amount of schedulers online. Valid range is .

For more information see, erlang:system_info(schedulers), and erlang:system_info(schedulers_online).

Sets the value of the node's trace control word to TCW. TCW should be an unsigned integer. For more information see documentation of the set_tcw function in the match specification documentation in the ERTS User's Guide.

Returns a list of tuples with information about miscellaneous allocated memory areas.

Each tuple contains an atom describing type of memory as first element and amount of allocated memory in bytes as second element. In those cases when there is information present about allocated and used memory, a third element is present. This third element contains the amount of used memory in bytes.

erlang:system_info(allocated_areas) is intended for debugging, and the content is highly implementation dependent. The content of the results will therefore change when needed without prior notice.

Note: The sum of these values is not the total amount of memory allocated by the emulator. Some values are part of other values, and some memory areas are not part of the result. If you are interested in the total amount of memory allocated by the emulator see erlang:memory/0,1.

Returns {Allocator, Version, Features, Settings}.

Types:

Explanation:

See also "System Flags Effecting erts_alloc" in erts_alloc(3).

Returns a list of the names of all allocators using the ERTS internal alloc_util framework as atoms. For more information see the "the alloc_util framework" section in the erts_alloc(3) documentation.

Returns information about the specified allocator. As of erts version 5.6.1 the return value is a list of {instance, InstanceNo, InstanceInfo} tuples where InstanceInfo contains information about a specific instance of the allocator. If Alloc is not a recognized allocator, undefined is returned. If Alloc is disabled, false is returned.

Note: The information returned is highly implementation dependent and may be changed, or removed at any time without prior notice. It was initially intended as a tool when developing new allocators, but since it might be of interest for others it has been briefly documented.

The recognized allocators are listed in erts_alloc(3). After reading the erts_alloc(3) documentation, the returned information should more or less speak for itself. But it can be worth explaining some things. Call counts are presented by two values. The first value is giga calls, and the second value is calls. mbcs, and sbcs are abbreviations for, respectively, multi-block carriers, and single-block carriers. Sizes are presented in bytes. When it is not a size that is presented, it is the amount of something. Sizes and amounts are often presented by three values, the first is current value, the second is maximum value since the last call to erlang:system_info({allocator, Alloc}), and the third is maximum value since the emulator was started. If only one value is present, it is the current value. fix_alloc memory block types are presented by two values. The first value is memory pool size and the second value used memory size.

Returns various size information for the specified allocator. The information returned is a subset of the information returned by erlang:system_info({allocator, Alloc}).

Returns an atom describing the build type of the runtime system. This is normally the atom opt for optimized. Other possible return values are debug, purify, quantify, purecov, gcov, valgrind, gprof, and lcnt. Possible return values may be added and/or removed at any time without prior notice.

Returns a two-tuple describing the C compiler used when compiling the runtime system. The first element is an atom describing the name of the compiler, or undefined if unknown. The second element is a term describing the version of the compiler, or undefined if unknown.

Returns a list containing miscellaneous information regarding the emulators internal I/O checking. Note, the content of the returned list may vary between platforms and over time. The only thing guaranteed is that a list is returned.

Returns the compatibility mode of the local node as an integer. The integer returned represents the Erlang/OTP release which the current emulator has been set to be backward compatible with. The compatibility mode can be configured at startup by using the command line flag +R, see erl(1).

Returns the CpuTopology which currently is used by the emulator. The CPU topology is used when binding schedulers to logical processors. The CPU topology used is the user defined CPU topology if such exists; otherwise, the automatically detected CPU topology if such exists. If no CPU topology exists, undefined is returned.

Types:

node refers to NUMA (non-uniform memory access) nodes, and thread refers to hardware threads (e.g. Intels hyper-threads).

A level in the CpuTopology term can be omitted if only one entry exists and the InfoList is empty.

thread can only be a sub level to core. core can be a sub level to either processor or node. processor can either be on the top level or a sub level to node. node can either be on the top level or a sub level to processor. That is, NUMA nodes can be processor internal or processor external. A CPU topology can consist of a mix of processor internal and external NUMA nodes, as long as each logical CPU belongs to one and only one NUMA node. Cache hierarchy is not part of the CpuTopology type yet, but will be in the future. Other things may also make it into the CPU topology in the future. In other words, expect the CpuTopology type to change.

Returns the user defined CpuTopology. For more information see the documentation of the erl +sct command line flag, and the documentation of the cpu_topology argument.

Returns the automatically detected CpuTopology. The emulator currently only detects the CPU topology on some newer Linux, Solaris, FreeBSD, and Windows systems. On Windows system with more than 32 logical processors the CPU topology is not detected.

For more information see the documentation of the cpu_topology argument.

Returns the CpuTopology which is used by the emulator. For more information see the documentation of the cpu_topology argument.

Returns the creation of the local node as an integer. The creation is changed when a node is restarted. The creation of a node is stored in process identifiers, port identifiers, and references. This makes it (to some extent) possible to distinguish between identifiers from different incarnations of a node. Currently valid creations are integers in the range 1..3, but this may (probably will) change in the future. If the node is not alive, 0 is returned.

Returns true if the emulator has been debug compiled; otherwise, false.

Returns a binary containing a string of distribution information formatted as in Erlang crash dumps. For more information see the "How to interpret the Erlang crash dumps" chapter in the ERTS User's Guide.

Returns a list of tuples {Node, ControllingEntity}, one entry for each connected remote node. The Node is the name of the node and the ControllingEntity is the port or pid responsible for the communication to that node. More specifically, the ControllingEntity for nodes connected via TCP/IP (the normal case) is the socket actually used in communication with the specific node.

Returns a string containing the erlang driver version used by the runtime system. It will be on the form "<major ver>.<minor ver>".

This option will be removed in a future release. The return value will always be false since the elib_malloc allocator has been removed.

Returns the value of the distribution buffer busy limit in bytes. This limit can be set on startup by passing the +zdbbl command line flag to erl.

Returns {fullsweep_after, integer()} which is the fullsweep_after garbage collection setting used by default. For more information see garbage_collection described below.

Returns a list describing the default garbage collection settings. A process spawned on the local node by a spawn or spawn_link will use these garbage collection settings. The default settings can be changed by use of system_flag/2. spawn_opt/4 can spawn a process that does not use the default settings.

Returns the current size of the shared (global) heap.

Returns a list of integers representing valid heap sizes in words. All Erlang heaps are sized from sizes in this list.

Returns the heap type used by the current emulator. Currently the following heap types exist:

Returns a binary containing a string of miscellaneous system information formatted as in Erlang crash dumps. For more information see the "How to interpret the Erlang crash dumps" chapter in the ERTS User's Guide.

Returns true if the emulator uses some kind of kernel-poll implementation; otherwise, false.

Returns a binary containing a string of loaded module information formatted as in Erlang crash dumps. For more information see the "How to interpret the Erlang crash dumps" chapter in the ERTS User's Guide.

Returns the detected number of logical processors configured on the system. The return value is either an integer, or the atom unknown if the emulator wasn't able to detect logical processors configured.

Returns the detected number of logical processors available to the Erlang runtime system. The return value is either an integer, or the atom unknown if the emulator wasn't able to detect logical processors available. The number of logical processors available is less than or equal to the number of logical processors online.

Returns the detected number of logical processors online on the system. The return value is either an integer, or the atom unknown if the emulator wasn't able to detect logical processors online. The number of logical processors online is less than or equal to the number of logical processors configured.

Returns a string containing the Erlang machine name.

Returns {min_heap_size, MinHeapSize} where MinHeapSize is the current system wide minimum heap size for spawned processes.

Returns {min_bin_vheap_size, MinBinVHeapSize} where MinBinVHeapSize is the current system wide minimum binary virtual heap size for spawned processes.

Returns the modified timing level (an integer) if modified timing has been enabled; otherwise, undefined. See the +T command line flag in the documentation of the erl(1) command for more information on modified timing.

Returns disabled, blocked, or enabled. A description of the return values:

See also erlang:system_flag(multi_scheduling, BlockState), erlang:system_info(multi_scheduling_blockers), and erlang:system_info(schedulers).

Returns a list of PIDs when multi-scheduling is blocked; otherwise, the empty list. The PIDs in the list is PIDs of the processes currently blocking multi-scheduling. A PID will only be present once in the list, even if the corresponding process has blocked multiple times.

See also erlang:system_flag(multi_scheduling, BlockState), erlang:system_info(multi_scheduling), and erlang:system_info(schedulers).

Returns a string containing the OTP release number.

Returns the number of processes currently existing at the local node as an integer. The same value as length(processes()) returns.

Returns the maximum number of concurrently existing processes at the local node as an integer. This limit can be configured at startup by using the command line flag +P, see erl(1).

Returns a binary containing a string of process and port information formatted as in Erlang crash dumps. For more information see the "How to interpret the Erlang crash dumps" chapter in the ERTS User's Guide.

Returns information on how user has requested schedulers to be bound or not bound.

NOTE: Even though user has requested schedulers to be bound, they might have silently failed to bind. In order to inspect actual scheduler bindings call erlang:system_info(scheduler_bindings).

For more information, see the erl +sbt command line argument, and erlang:system_info(scheduler_bindings).

Returns information on currently used scheduler bindings.

A tuple of a size equal to erlang:system_info(schedulers) is returned. The elements of the tuple are integers or the atom unbound. Logical processor identifiers are represented as integers. The Nth element of the tuple equals the current binding for the scheduler with the scheduler identifier equal to N. E.g., if the schedulers have been bound, element(erlang:system_info(scheduler_id), erlang:system_info(scheduler_bindings)) will return the identifier of the logical processor that the calling process is executing on.

Note that only schedulers online can be bound to logical processors.

For more information, see the erl +sbt command line argument, erlang:system_info(schedulers_online).

Returns the scheduler id (SchedulerId) of the scheduler thread that the calling process is executing on. SchedulerId is a positive integer; where . See also erlang:system_info(schedulers).

Returns the number of scheduler threads used by the emulator. Scheduler threads online schedules Erlang processes and Erlang ports, and execute Erlang code and Erlang linked in driver code.

The number of scheduler threads is determined at emulator boot time and cannot be changed after that. The amount of schedulers online can however be changed at any time.

See also erlang:system_flag(schedulers_online, SchedulersOnline), erlang:system_info(schedulers_online), erlang:system_info(scheduler_id), erlang:system_flag(multi_scheduling, BlockState), erlang:system_info(multi_scheduling), and and erlang:system_info(multi_scheduling_blockers).

Returns the amount of schedulers online. The scheduler identifiers of schedulers online satisfy the following relationship: .

For more information, see erlang:system_info(schedulers), and erlang:system_flag(schedulers_online, SchedulersOnline).

Returns true if the emulator has been compiled with smp support; otherwise, false.

Returns a string containing version number and some important properties such as the number of schedulers.

Returns a string containing the processor and OS architecture the emulator is built for.

Returns true if the emulator has been compiled with thread support; otherwise, false is returned.

Returns the number of async threads in the async thread pool used for asynchronous driver calls (driver_async()) as an integer.

Returns the value of the node's trace control word. For more information see documentation of the function get_tcw in "Match Specifications in Erlang", ERTS User's Guide.

The runtime system rereads the CPU information available and updates its internally stored information about the detected CPU topology and the amount of logical processors configured, online, and available. If the CPU information has changed since the last time it was read, the atom changed is returned; otherwise, the atom unchanged is returned. If the CPU information has changed you probably want to adjust the amount of schedulers online. You typically want to have as many schedulers online as logical processors available.

Returns a string containing the version number of the emulator.

Same as {wordsize, internal}.

Returns the size of Erlang term words in bytes as an integer, i.e. on a 32-bit architecture 4 is returned, and on a pure 64-bit architecture 8 is returned. On a halfword 64-bit emulator, 4 is returned, as the Erlang terms are stored using a virtual wordsize of half the system's wordsize.

Returns the true wordsize of the emulator, i.e. the size of a pointer, in bytes as an integer. On a pure 32-bit architecture 4 is returned, on both a halfword and pure 64-bit architecture, 8 is returned.

If a garbage collection in the system takes at least Time wallclock milliseconds, a message {monitor, GcPid, long_gc, Info} is sent to MonitorPid. GcPid is the pid that was garbage collected and Info is a list of two-element tuples describing the result of the garbage collection. One of the tuples is {timeout, GcTime} where GcTime is the actual time for the garbage collection in milliseconds. The other tuples are tagged with heap_size, heap_block_size, stack_size, mbuf_size, old_heap_size, and old_heap_block_size. These tuples are explained in the documentation of the gc_start trace message (see erlang:trace/3). New tuples may be added, and the order of the tuples in the Info list may be changed at any time without prior notice.

If a garbage collection in the system results in the allocated size of a heap being at least Size words, a message {monitor, GcPid, large_heap, Info} is sent to MonitorPid. GcPid and Info are the same as for long_gc above, except that the tuple tagged with timeout is not present. Note: As of erts version 5.6 the monitor message is sent if the sum of the sizes of all memory blocks allocated for all heap generations is equal to or larger than Size. Previously the monitor message was sent if the memory block allocated for the youngest generation was equal to or larger than Size.

If a process in the system gets suspended because it sends to a busy port, a message {monitor, SusPid, busy_port, Port} is sent to MonitorPid. SusPid is the pid that got suspended when sending to Port.

If a process in the system gets suspended because it sends to a process on a remote node whose inter-node communication was handled by a busy port, a message {monitor, SusPid, busy_dist_port, Port} is sent to MonitorPid. SusPid is the pid that got suspended when sending through the inter-node communication port Port.

If a process is put into or removed from the run queue a message, {profile, Pid, State, Mfa, Ts}, is sent to ProfilerPid. Running processes that is reinserted into the run queue after having been preemptively scheduled out will not trigger this message.

If a port is put into or removed from the run queue a message, {profile, Port, State, 0, Ts}, is sent to ProfilerPid.

If a scheduler is put to sleep or awoken a message, {profile, scheduler, Id, State, NoScheds, Ts}, is sent to ProfilerPid.

If a synchronous call to a port from a process is done, the calling process is considered not runnable during the call runtime to the port. The calling process is notified as inactive and subsequently active when the port callback returns.

All processes currently existing.

All processes that will be created in the future.

All currently existing processes and all processes that will be created in the future.

Set all trace flags except {tracer, Tracer} and cpu_timestamp that are in their nature different than the others.

Trace sending of messages.

Message tags: send, send_to_non_existing_process.

Trace receiving of messages.

Message tags: 'receive'.

Trace process related events.

Message tags: spawn, exit, register, unregister, link, unlink, getting_linked, getting_unlinked.

Trace certain function calls. Specify which function calls to trace by calling erlang:trace_pattern/3.

Message tags: call, return_from.

Used in conjunction with the call trace flag. The call, return_from and return_to trace messages are inhibited if this flag is set, but if there are match specs they are executed as normal.

Silent mode is inhibited by executing erlang:trace(_, false, [silent|_]), or by a match spec executing the {silent, false} function.

The silent trace flag facilitates setting up a trace on many or even all processes in the system. Then the interesting trace can be activated and deactivated using the {silent,Bool} match spec function, giving a high degree of control of which functions with which arguments that triggers the trace.

Message tags: call, return_from, return_to. Or rather, the absence of.

Used in conjunction with the call trace flag. Trace the actual return from a traced function back to its caller. Only works for functions traced with the local option to erlang:trace_pattern/3.

The semantics is that a trace message is sent when a call traced function actually returns, that is, when a chain of tail recursive calls is ended. There will be only one trace message sent per chain of tail recursive calls, why the properties of tail recursiveness for function calls are kept while tracing with this flag. Using call and return_to trace together makes it possible to know exactly in which function a process executes at any time.

To get trace messages containing return values from functions, use the {return_trace} match_spec action instead.

Message tags: return_to.

Trace scheduling of processes.

Message tags: in, and out.

Trace scheduling of an exiting processes.

Message tags: in_exiting, out_exiting, and out_exited.

Trace garbage collections of processes.

Message tags: gc_start, gc_end.

Include a time stamp in all trace messages. The time stamp (Ts) is of the same form as returned by erlang:now().

A global trace flag for the Erlang node that makes all trace timestamps be in CPU time, not wallclock. It is only allowed with PidSpec==all. If the host machine operating system does not support high resolution CPU time measurements, trace/3 exits with badarg.

Used in conjunction with the call trace flag. {M, F, Arity} will be specified instead of {M, F, Args} in call trace messages.

Makes any process created by a traced process inherit its trace flags, including the set_on_spawn flag.

Makes the first process created by a traced process inherit its trace flags, excluding the set_on_first_spawn flag.

Makes any process linked by a traced process inherit its trace flags, including the set_on_link flag.

Makes the first process linked to by a traced process inherit its trace flags, excluding the set_on_first_link flag.

Specify where to send the trace messages. Tracer must be the pid of a local process or the port identifier of a local port. If this flag is not given, trace messages will be sent to the process that called erlang:trace/3.

When Pid receives the message Msg.

When Pid sends the message Msg to the process To.

When Pid sends the message Msg to the non-existing process To.

When Pid calls a traced function. The return values of calls are never supplied, only the call and its arguments.

Note that the trace flag arity can be used to change the contents of this message, so that Arity is specified instead of Args.

When Pid returns to the specified function. This trace message is sent if both the call and the return_to flags are set, and the function is set to be traced on local function calls. The message is only sent when returning from a chain of tail recursive function calls where at least one call generated a call trace message (that is, the functions match specification matched and {message, false} was not an action).

When Pid returns from the specified function. This trace message is sent if the call flag is set, and the function has a match specification with a return_trace or exception_trace action.

When Pid exits from the specified function due to an exception. This trace message is sent if the call flag is set, and the function has a match specification with an exception_trace action.

When Pid spawns a new process Pid2 with the specified function call as entry point.

Note that Args is supposed to be the argument list, but may be any term in the case of an erroneous spawn.

When Pid exits with reason Reason.

When Pid links to a process Pid2.

When Pid removes the link from a process Pid2.

When Pid gets linked to a process Pid2.

When Pid gets unlinked from a process Pid2.

When Pid gets the name RegName registered.

When Pid gets the name RegName unregistered. Note that this is done automatically when a registered process exits.

When Pid is scheduled to run. The process will run in function {M, F, Arity}. On some rare occasions the current function cannot be determined, then the last element Arity is 0.

When Pid is scheduled out. The process was running in function {M, F, Arity}. On some rare occasions the current function cannot be determined, then the last element Arity is 0.

Sent when garbage collection is about to be started. Info is a list of two-element tuples, where the first element is a key, and the second is the value. You should not depend on the tuples have any defined order. Currently, the following keys are defined:

All sizes are in words.

Sent when garbage collection is finished. Info contains the same kind of list as in the gc_start message, but the sizes reflect the new sizes after garbage collection.

Return a list of atoms indicating what kind of traces is enabled for the process. The list will be empty if no traces are enabled, and one or more of the followings atoms if traces are enabled: send, 'receive', set_on_spawn, call, return_to, procs, set_on_first_spawn, set_on_link, running, garbage_collection, timestamp, and arity. The order is arbitrary.

Return the identifier for process or port tracing this process. If this process is not being traced, the return value will be [].

Return global if this function is traced on global function calls, local if this function is traced on local function calls (i.e local and global function calls), and false if neither local nor global function calls are traced.

Return the match specification for this function, if it has one. If the function is locally or globally traced but has no match specification defined, the returned value is [].

Return the meta trace tracer process or port for this function, if it has one. If the function is not meta traced the returned value is false, and if the function is meta traced but has once detected that the tracer proc is invalid, the returned value is [].

Return the meta trace match specification for this function, if it has one. If the function is meta traced but has no match specification defined, the returned value is [].

Return the call count value for this function or true for the pseudo function on_load if call count tracing is active. Return false otherwise. See also erlang:trace_pattern/3.

Return the call time values for this function or true for the pseudo function on_load if call time tracing is active. Returns false otherwise. The call time values returned, [{Pid, Count, S, Us}], is a list of each process that has executed the function and its specific counters. See also erlang:trace_pattern/3.

Return a list containing the {Item, Value} tuples for all other items, or return false if no tracing is active for this function.

All exported functions of any arity named Function in module Module.

All exported functions in module Module.

All exported functions in all loaded modules.

Disable tracing for the matching function(s). Any match specification will be removed.

Enable tracing for the matching function(s).

A list of match specifications. An empty list is equivalent to true. See the ERTS User's Guide for a description of match specifications.

For the FlagList option call_count and call_time: restart the existing counters. The behaviour is undefined for other FlagList options.

For the FlagList option call_count and call_time: pause the existing counters. The behaviour is undefined for other FlagList options.

Turn on or off call tracing for global function calls (that is, calls specifying the module explicitly). Only exported functions will match and only global calls will generate trace messages. This is the default.

Turn on or off call tracing for all types of function calls. Trace messages will be sent whenever any of the specified functions are called, regardless of how they are called. If the return_to flag is set for the process, a return_to message will also be sent when this function returns to its caller.

Turn on or off meta tracing for all types of function calls. Trace messages will be sent to the tracer process or port Pid whenever any of the specified functions are called, regardless of how they are called. If no Pid is specified, self() is used as a default tracer process.

Meta tracing traces all processes and does not care about the process trace flags set by trace/3, the trace flags are instead fixed to [call, timestamp].

The match spec function {return_trace} works with meta trace and send its trace message to the same tracer process.

Starts (MatchSpec == true) or stops (MatchSpec == false) call count tracing for all types of function calls. For every function a counter is incremented when the function is called, in any process. No process trace flags need to be activated.

If call count tracing is started while already running, the count is restarted from zero. Running counters can be paused with MatchSpec == pause. Paused and running counters can be restarted from zero with MatchSpec == restart.

The counter value can be read with erlang:trace_info/2.

Starts (MatchSpec == true) or stops (MatchSpec == false) call time tracing for all types of function calls. For every function a counter is incremented when the function is called. Time spent in the function is accumulated in two other counters, seconds and micro-seconds. The counters are stored for each call traced process.

If call time tracing is started while already running, the count and time is restarted from zero. Running counters can be paused with MatchSpec == pause. Paused and running counters can be restarted from zero with MatchSpec == restart.

The counter value can be read with erlang:trace_info/2.