Erlang Run-Time System Application
(ERTS)
Copyright © 1997-2019 Ericsson AB. All Rights Reserved.
Erlang Run-Time System Application (ERTS) 10.6
December 9, 2019
Copyright © 1997-2019 Ericsson AB. All Rights Reserved.
Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance
with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless
required by applicable law or agreed to in writing, software distributed under the License is distributed on an
"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See
the License for the specific language governing permissions and limitations under the License. Ericsson AB. All
Rights Reserved..
December 9, 2019
Ericsson AB. All Rights Reserved.: Erlang Run-Time System Application (ERTS) | 1
1.1Introduction
2 | Ericsson AB. All Rights Reserved.: Erlang Run-Time System Application (ERTS)
1 ERTS User's Guide
1.1Introduction
1.1.1 Scope
The Erlang Runtime System Application, ERTS, contains functionality necessary to run the Erlang system.
Note:
By default, ERTS is only guaranteed to be compatible with other Erlang/OTP components from the same release
as ERTS itself.
For information on how to communicate with Erlang/OTP components from earlier releases, see the documentation
of system flag +R in erl(1).
1.1.2 Prerequisites
It is assumed that the reader is familiar with the Erlang programming language.
1.2Communication in Erlang
Communication in Erlang is conceptually performed using asynchronous signaling. All different executing entities,
such as processes and ports, communicate through asynchronous signals. The most commonly used signal is a message.
Other common signals are exit, link, unlink, monitor, and demonitor signals.
1.2.1 Passing of Signals
The amount of time that passes between a signal is sent and the arrival of the signal at the destination is unspecified
but positive. If the receiver has terminated, the signal does not arrive, but it can trigger another signal. For example, a
link signal sent to a non-existing process triggers an exit signal, which is sent back to where the link signal originated
from. When communicating over the distribution, signals can be lost if the distribution channel goes down.
The only signal ordering guarantee given is the following: if an entity sends multiple signals to the same destination
entity, the order is preserved; that is, if A sends a signal S1 to B, and later sends signal S2 to B, S1 is guaranteed
not to arrive after S2.
1.2.2 Synchronous Communication
Some communication is synchronous. If broken down into pieces, a synchronous communication operation consists of
two asynchronous signals; one request signal and one reply signal. An example of such a synchronous communication
is a call to erlang:process_info/2 when the first argument is not self(). The caller sends an asynchronous
signal requesting information, and then waits for the reply signal containing the requested information. When the
request signal reaches its destination, the destination process replies with the requested information.
1.2.3 Implementation
The implementation of different asynchronous signals in the virtual machine can vary over time, but the behavior
always respects this concept of asynchronous signals being passed between entities as described above.
1.3Time and Time Correction in Erlang
Ericsson AB. All Rights Reserved.: Erlang Run-Time System Application (ERTS) | 3
By inspecting the implementation, you might notice that some specific signal gives a stricter guarantee than described
above. It is of vital importance that such knowledge about the implementation is not used by Erlang code, as the
implementation can change at any time without prior notice.
Examples of major implementation changes:
• As from ERTS 5.5.2 exit signals to processes are truly asynchronously delivered.
• As from ERTS 5.10 all signals from processes to ports are truly asynchronously delivered.
1.3Time and Time Correction in Erlang
1.3.1 New Extended Time Functionality
Note:
As from Erlang/OTP 18 (ERTS 7.0) the time functionality has been extended. This includes a new API for time
and time warp modes that change the system behavior when system time changes.
The default time warp mode has the same behavior as before, and the old API still works. Thus, you are not required
to change anything unless you want to. However, you are strongly encouraged to use the new API instead of the
old API based on erlang:now/0. erlang:now/0 is deprecated, as it is and will be a scalability bottleneck.
By using the new API, you automatically get scalability and performance improvements. This also enables you to
use the multi-time warp mode that improves accuracy and precision of time measurements.
1.3.2 Terminology
To make it easier to understand this section, some terms are defined. This is a mix of our own terminology (Erlang/
OS system time, Erlang/OS monotonic time, time warp) and globally accepted terminology.
Monotonically Increasing
In a monotonically increasing sequence of values, all values that have a predecessor are either larger than or equal
to its predecessor.
Strictly Monotonically Increasing
In a strictly monotonically increasing sequence of values, all values that have a predecessor are larger than its
predecessor.
UT1
Universal Time. UT1 is based on the rotation of the earth and conceptually means solar time at 0° longitude.
UTC
Coordinated Universal Time. UTC almost aligns with UT1. However, UTC uses the SI definition of a second, which
has not exactly the same length as the second used by UT1. This means that UTC slowly drifts from UT1. To keep
UTC relatively in sync with UT1, leap seconds are inserted, and potentially also deleted. That is, an UTC day can be
86400, 86401, or 86399 seconds long.
POSIX Time
Time since Epoch. Epoch is defined to be 00:00:00 UTC, 1970-01-01. A day in POSIX time is defined to be exactly
86400 seconds long. Strangely enough, Epoch is defined to be a time in UTC, and UTC has another definition of how
long a day is. Quoting the Open Group "POSIX time is therefore not necessarily UTC, despite its appearance".
The effect of this is that when an UTC leap second is inserted, POSIX time either stops for a second, or repeats the
