Erlang Run-Time System Application (ERTS)

User's Guide

Version 9.3

- User's Guide
- Reference Manual
- Release Notes
- PDF
- Top

- Expand All
- Contract All

### Chapters

- Introduction
  - Top of chapter
  - Scope
  - Prerequisites
- Communication in Erlang
  - Top of chapter
  - Passing of Signals
  - Synchronous Communication
  - Implementation
- Time and Time Correction in Erlang
  - Top of chapter
  - New Extended Time Functionality
  - Terminology
  - Introduction
  - Time Correction
  - Time Warp Safe Code
  - Time Warp Modes
  - New Time API
  - Support of Both New and Old OTP Releases
- Match Specifications in Erlang
  - Top of chapter
  - Grammar
  - Function Descriptions
  - Match target
  - Variables and Literals
  - Execution of the Match
  - Differences between Match Specifications in ETS and Tracing
  - Tracing Examples
  - ETS Examples
- How to Interpret the Erlang Crash Dumps
  - Top of chapter
  - General Information
  - Scheduler Information
  - Memory Information
  - Internal Table Information
  - Allocated Areas
  - Allocator
  - Process Information
  - Port Information
  - ETS Tables
  - Timers
  - Distribution Information
  - Loaded Module Information
  - Fun Information
  - Process Data
  - Atoms
  - Disclaimer
- How to Implement an Alternative Carrier for the Erlang Distribution
  - Top of chapter
  - Introduction
  - The Driver
  - Putting It All Together
- The Abstract Format
  - Top of chapter
  - Module Declarations and Forms
  - Atomic Literals
  - Patterns
  - Expressions
  - Clauses
  - Guards
  - Types
  - The Abstract Format after Preprocessing
- tty - A Command-Line Interface
  - Top of chapter
  - Normal Mode
  - Shell Break Mode
- How to Implement a Driver
  - Top of chapter
  - Introduction
  - Sample Driver
  - Compiling and Linking the Sample Driver
  - Calling a Driver as a Port in Erlang
  - Sample Asynchronous Driver
  - An Asynchronous Driver Using driver_async
- Inet Configuration
  - Top of chapter
  - Introduction
  - Configuration Data
  - User Configuration Example
- External Term Format
  - Top of chapter
  - Introduction
  - Distribution Header
  - ATOM_CACHE_REF
  - SMALL_INTEGER_EXT
  - INTEGER_EXT
  - FLOAT_EXT
  - REFERENCE_EXT
  - PORT_EXT
  - PID_EXT
  - SMALL_TUPLE_EXT
  - LARGE_TUPLE_EXT
  - MAP_EXT
  - NIL_EXT
  - STRING_EXT
  - LIST_EXT
  - BINARY_EXT
  - SMALL_BIG_EXT
  - LARGE_BIG_EXT
  - NEW_REFERENCE_EXT
  - FUN_EXT
  - NEW_FUN_EXT
  - EXPORT_EXT
  - BIT_BINARY_EXT
  - NEW_FLOAT_EXT
  - ATOM_UTF8_EXT
  - SMALL_ATOM_UTF8_EXT
  - ATOM_EXT (deprecated)
  - SMALL_ATOM_EXT (deprecated)
- Distribution Protocol
  - Top of chapter
  - EPMD Protocol
  - Distribution Handshake
  - Protocol between Connected Nodes
  - New Ctrlmessages for distrvsn = 1 (Erlang/OTP R4)
  - New Ctrlmessages for distrvsn = 2
  - New Ctrlmessages for distrvsn = 3 (Erlang/OTP R5C)
  - New Ctrlmessages for distrvsn = 4 (Erlang/OTP R6)

# 2 Communication 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.

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

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

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

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.