# Processes ## Processes Erlang is designed for massive concurrency. Erlang processes are lightweight (grow and shrink dynamically) with a small memory footprint, fast to create and terminate, and the scheduling overhead is low. ## Process Creation A process is created by calling [`spawn()`](`erlang:spawn/3`): ```erlang spawn(Module, Name, Args) -> pid() Module = Name = atom() Args = [Arg1,...,ArgN] ArgI = term() ``` `spawn()` creates a new process and returns the pid. The new process starts executing in `Module:Name(Arg1,...,ArgN)` where the arguments are the elements of the (possibly empty) `Args` argument list. There exist a number of different `spawn` BIFs: - [`spawn/1,2,3,4`](`erlang:spawn/4`) - [`spawn_link/1,2,3,4`](`erlang:spawn_link/4`) - [`spawn_monitor/1,2,3,4`](`erlang:spawn_monitor/4`) - [`spawn_opt/2,3,4,5`](`erlang:spawn_opt/5`) - [`spawn_request/1,2,3,4,5`](`erlang:spawn_request/5`) ## Registered Processes Besides addressing a process by using its pid, there are also BIFs for registering a process under a name. The name must be an atom and is automatically unregistered if the process terminates: | BIF | Description | | ------------------------------------- | -------------------------------------------------------------------------------------- | | [`register(Name, Pid)`](`register/2`) | Associates the name `Name`, an atom, with the process `Pid`. | | `registered/0` | Returns a list of names that have been registered using [`register/2`](`register/2`). | | [`whereis(Name)`](`whereis/1`) | Returns the pid registered under `Name`, or `undefined` if the name is not registered. | _Table: Name Registration BIFs_ ## Process Aliases When sending a message to a process, the receiving process can be identified by a [Pid](data_types.md#pid), a [registered name](ref_man_processes.md#registered-processes), or a _process alias_ which is a term of the type [reference](data_types.md#reference). The typical use case that process aliases were designed for is a request/reply scenario. Using a process alias when sending the reply makes it possible for the receiver of the reply to prevent the reply from reaching its message queue if the operation times out or if the connection between the processes is lost. A process alias can be used as an identifier of the receiver when sending a message using the [send operator (`!`)](expressions.md#send) or send BIFs such as `erlang:send/2`. As long as the process alias is active, messages will be delivered the same way as if the process identifier of the process that created the alias had been used. When the alias has been deactivated, messages sent using the alias will be dropped before entering the message queue of the receiver. Note that messages that at deactivation time already have entered the message queue will _not_ be removed. A process alias is created either by calling one of the [`alias/0,1`](`erlang:alias/0`) BIFs or by creating an alias and a monitor simultaneously. If the alias is created together with a monitor, the same reference will be used both as monitor reference and alias. Creating a monitor and an alias at the same time is done by passing the `{alias, _}` option to the [`monitor/3`](`erlang:monitor/3`) BIF. The `{alias, _}` option can also be passed when creating a monitor via [`spawn_opt()`](`erlang:spawn_opt/5`), or [`spawn_request()`](`erlang:spawn_request/5`). A process alias can be deactivated by the process that created it by calling the [`unalias/1`](`erlang:unalias/1`) BIF. It is also possible to automatically deactivate an alias on certain events. See the documentation of the [`alias/1`](`erlang:alias/1`) BIF, and the `{alias, _}` option of the [`monitor/3`](`erlang:monitor/3`) BIF for more information about automatic deactivation of aliases. It is _not_ possible to: - create an alias identifying a process other than the caller. - deactivate an alias unless it identifies the caller. - look up an alias. - look up the process identified by an alias. - check if an alias is active or not. - check if a reference is an alias. These are all intentional design decisions relating to performance, scalability, and distribution transparency. ## Process Termination When a process terminates, it always terminates with an _exit reason_. The reason can be any term. A process is said to terminate _normally_ if the exit reason is the atom `normal`. A process with no more code to execute terminates normally. A process terminates with an exit reason `{Reason,Stack}` when a run-time error occurs. See [Exit Reasons](errors.md#exit_reasons). A process can terminate itself by calling one of the following BIFs: - [`exit(Reason)`](`exit/1`) - [`error(Reason)`](`erlang:error/1`) - [`error(Reason, Args)`](`erlang:error/2`) The process then terminates with reason `Reason` for [`exit/1`](`exit/1`) or `{Reason,Stack}` for the others. A process can also be terminated if it receives an exit signal with an exit reason other than `normal`, see [Error Handling](ref_man_processes.md#errors). ## Signals [](){: #message-sending } All communication between Erlang processes and Erlang ports is done by sending and receiving asynchronous signals. The most common signals are Erlang message signals. A message signal can be sent using the [send operator `!`](expressions.md#send). A received message can be fetched from the message queue by the receiving process using the [`receive`](expressions.md#receive) expression. [](){: #sync-comm } Synchronous communication can be broken down into multiple asynchronous signals. An example of such a synchronous communication is a call to the `erlang:process_info/2` BIF when the first argument does not equal the process identifier of the calling process. The caller sends an asynchronous signal requesting information, and then blocks waiting for the reply signal containing the requested information. When the request signal reaches its destination, the destination process replies with the requested information. ### Sending Signals There are many signals that processes and ports use to communicate. The list below contains the most important signals. In all the cases of request/reply signal pairs, the request signal is sent by the process calling the specific BIF, and the reply signal is sent back to it when the requested operation has been performed. - **`message`** - Sent when using the [send operator `!`](expressions.md#send), or when calling one of the [`erlang:send/2,3`](`erlang:send/2`) or [`erlang:send_nosuspend/2,3`](`erlang:send_nosuspend/2`) BIFs. - **`link`** - Sent when calling the [link/1](`erlang:link/1`) BIF. - **`unlink`** - Sent when calling the [unlink/1](`erlang:unlink/1`) BIF. - **`exit`** - Sent either when explicitly sending an `exit` signal by calling the [exit_signal/2](`erlang:exit_signal/2`) BIF, or when a [linked process terminates](ref_man_processes.md#sending_exit_signals). If the signal is sent due to a link, the signal is sent after all [_directly visible Erlang resources_](ref_man_processes.md#visible-resources) used by the process have been released. - **`monitor`** - Sent when calling one of the [monitor/2,3](`erlang:monitor/3`) BIFs. - **`demonitor`** - Sent when calling one of the [demonitor/1,2](`erlang:demonitor/1`) BIFs, or when a process monitoring another process terminates. - **`down`** - Sent by a [monitored process or port that terminates](ref_man_processes.md#monitors). The signal is sent after all [_directly visible Erlang resources_](ref_man_processes.md#visible-resources) used by the process or the port have been released. - **`change`** - Sent by the [clock service](ref_man_processes.md#runtime-service) on the local runtime system, when the [time offset](`erlang:time_offset/0`) changes, to processes which have [monitored the `time_offset`](`erlang:monitor/2`). - **`group_leader`** - Sent when calling the [group_leader/2](`erlang:group_leader/2`) BIF. - **`spawn_request`/`spawn_reply`, `open_port_request`/`open_port_reply`** - Sent due to a call to one of the [`spawn/1,2,3,4`](`erlang:spawn/4`), [`spawn_link/1,2,3,4`](`erlang:spawn_link/4`), [`spawn_monitor/1,2,3,4`](`erlang:spawn_monitor/4`), [`spawn_opt/2,3,4,5`](`erlang:spawn_opt/5`), [`spawn_request/1,2,3,4,5`](`erlang:spawn_request/5`), or `erlang:open_port/2` BIFs. The request signal is sent to the [spawn service](ref_man_processes.md#runtime-service) which responds with the reply signal. - **`alive_request`/`alive_reply`** - Sent due to a call to the [is_process_alive/1](`erlang:is_process_alive/1`) BIF. - **`garbage_collect_request`/`garbage_collect_reply`, `check_process_code_request`/`check_process_code_reply`, `process_info_request`/`process_info_reply`** - Sent due to a call to one of the [garbage_collect/1,2](`erlang:garbage_collect/1`), [erlang:check_process_code/2,3](`erlang:check_process_code/2`), or [process_info/1,2](`erlang:process_info/2`) BIFs. Note that if the request is directed towards the caller itself and it is a synchronous request, no signaling will be performed and the caller will instead synchronously perform the request before returning from the BIF. - **`port_command`, `port_connect`, `port_close`** - Sent by a process to a port on the local node using the [send operator (`!`)](expressions.md#send), or by calling one of the [`send()`](`erlang:send/2`) BIFs. The signal is sent by passing a term of the format `{Owner, {command, Data}}`, `{Owner, {connect, Pid}}`, or `{Owner, close}` as message. - **`port_command_request`/`port_command_reply`, `port_connect_request`/`port_connect_reply`, `port_close_request`/`port_close_reply`, `port_control_request`/`port_control_reply`, `port_call_request`/`port_call_reply`, `port_info_request`/`port_info_reply`** - Sent due to a call to one of the [`erlang:port_command/2,3`](`erlang:port_command/2`), `erlang:port_connect/2`, `erlang:port_close/1`, `erlang:port_control/3`, `erlang:port_call/3`, [`erlang:port_info/1,2`](`erlang:port_info/1`) BIFs. The request signal is sent to a port on the local node which responds with the reply signal. - **`register_name_request`/`register_name_reply`, `unregister_name_request`/`unregister_name_reply`, `whereis_name_request`/`whereis_name_reply`** - Sent due to a call to one of the [`register/2`](`erlang:register/2`), [`unregister/1`](`erlang:unregister/1`), or [`whereis/1`](`erlang:whereis/1`) BIFs. The request signal is sent to the [name service](ref_man_processes.md#runtime-service), which responds with the reply signal. - **`timer_start_request`/`timer_start_reply`, `timer_cancel_request`/`timer_cancel_reply`** - Sent due to a call to one of the [`erlang:send_after/3,4`](`erlang:send_after/3`), [`erlang:start_timer/3,4`](`erlang:start_timer/3`), or [`erlang:cancel_timer/1,2`](`erlang:cancel_timer/1`) BIFs. The request signal is sent to the [timer service](ref_man_processes.md#runtime-service) which responds with the reply signal. [](){: #runtime-service } The clock service, the name service, the timer service, and the spawn service mentioned previously are services provided by the runtime system. Each of these services consists of multiple independently executing entities. Such a service can be viewed as a group of processes, and could actually be implemented like that. Since each service consists of multiple independently executing entities, the order between multiple signals sent from one service to one process is _not_ preserved. Note that this does _not_ violate the [signal ordering guarantee](ref_man_processes.md#signal-delivery) of the language. The realization of the signals described earlier may change both at runtime and due to changes in implementation. You may be able to detect such changes using `receive` tracing or by inspecting message queues. However, these are internal implementation details of the runtime system that you should _not_ rely on. As an example, many of the reply signals are ordinary message signals. When the operation is synchronous, the reply signals do not have to be message signals. The current implementation takes advantage of this and, depending on the state of the system, uses alternative ways of delivering the reply signals. The implementation of these reply signals may also, at any time, be changed to not use message signals where it previously did. ### Receiving Signals Signals are received asynchronously and automatically. There is nothing a process must do to handle the reception of signals, or can do to prevent it. In particular, signal reception is _not_ tied to the execution of a [`receive`](expressions.md#receive) expression, but can happen anywhere in the execution flow of a process. When a signal is received by a process, some kind of action is taken. The specific action taken depends on the signal type, contents of the signal, and the state of the receiving process. Actions taken for the most common signals: - **`message`** - If the message signal was sent using a [process alias](ref_man_processes.md#process-aliases) that is no longer active, the message signal will be dropped; otherwise, if the alias is still active or the message signal was sent by other means, the message is added to the message queue. When the message has been added to the message queue, the receiving process can fetch the message from the message queue using the [`receive`](expressions.md#receive) expression. - **`link`, `unlink`** - Very simplified, it can be viewed as updating process-local information about the link. A detailed description of the [link protocol](`e:erts:erl_dist_protocol.md#link_protocol`) can be found in the _Distribution Protocol_ chapter of the _ERTS User's Guide_. - **`exit`** - Set the receiver in an exiting state, drop the signal, or convert the signal into a message and add it to the message queue. If the receiver is set in an exiting state, no more Erlang code will be executed and the process is scheduled for termination. The section [_Receiving Exit Signals_](ref_man_processes.md#receiving_exit_signals) below gives more details on the action taken when an `exit` signal is received. - **`monitor`, `demonitor`** - Update process-local information about the monitor. - **`down`, `change`** - Convert into a message if the corresponding monitor is still active; otherwise, drop the signal. If the signal is converted into a message, it is also added to the message queue. - **`group_leader`** - Change the group leader of the process. - **`spawn_reply`** - Convert into a message or drop the signal, depending on the reply and how the `spawn_request` signal was configured. If the signal is converted into a message, it is also added to the message queue. For more information see the [`spawn_request()`](`erlang:spawn_request/5`) BIF. - **`alive_request`** - Schedule execution of the _is alive_ test. If the process is in an exiting state, the _is alive_ test will not be executed until after all [_directly visible Erlang resources_](ref_man_processes.md#visible-resources) used by the process have been released. The `alive_reply` will be sent after the _is alive_ test has executed. - **`process_info_request`, `garbage_collect_request`, `check_process_code_request`** - Schedule execution of the requested operation. The reply signal will be sent when the operation has been executed. Note that some of the actions taken when a signal is received involve _scheduling_ further actions which will result in a reply signal when these scheduled actions have completed. This implies that the reply signals may be sent in a different order than the order of the incoming signals that triggered these operations. This does, however, _not_ violate the [signal ordering guarantee](ref_man_processes.md#signal-delivery) of the language. [](){: #message-queue-order } #### Adding Messages to the Message Queue When a message signal is received, the action taken is to add the message to the message queue. The actions of other signals, upon reception, may also add messages to the message queue ([see above](ref_man_processes.md#receiving-signals)). Unless the receiving process has enabled priority messages, all messages are added to the end of the message queue. In the case that the receiver has not enabled priority messages, the order of the messages in the message queue will reflect the order in which the signals corresponding to the messages in the queue were received. Messages corresponding to signals from the same sender will then also be ordered in the same order as the signals were sent due to the [signal ordering guarantee](ref_man_processes.md#signal-delivery) of the language. [](){: #priority-messages } As of OTP 28.0, a process may [enable reception of priority messages](ref_man_processes.md#enable-prio-msg-recv). If the receiving process has enabled priority messages, the receiver will at reception of a message signal, or another signal that is converted into a message, check if it should be accepted as a priority message or not. If accepted as a priority message, it will be added after the last accepted priority message in the queue; otherwise, it will be treated as an ordinary message and will be added at the end of the message queue.  Figure 1. When messages that have been accepted as priority messages exist in the message queue, the order of the messages in the message queue will *not* reflect the order in which the signals corresponding to the messages in the queue were received. However, the order of priority messages corresponds to the order in which those corresponding signals were received, and the order of ordinary messages corresponds to the order in which those corresponding signals were received. Thus, two messages sent from the same sender may be in a different order from the order in which they were sent. Note that priority messages *do not* violate the [signal ordering guarantee](ref_man_processes.md#signal-delivery) of the language. The signals are still delivered in the same order to the receiving process. The *only* difference is how messages are added to the message queue after the signals have been received by the receiving process. A [`receive`](expressions.md#receive) expression will select the first message, from the start, in the message queue that matches, just as if only ordinary messages exist in the message queue. The total message queue length in figure 1 equals `P+M`. The lengths `P` and `M` are not visible; only the total message queue length can be determined. There is no way for the Erlang code to distinguish a priority message from an ordinary message when fetching a message from the message queue. Such knowledge needs to be part of the message protocol that the process should adhere to. [](){: #enable-prio-msg-recv } #### Enabling Priority Message Reception [](){: #priority-message-warning } > #### Warning {: .warning } > > Priority messages are intended to solve very specific problems where it > previously was very hard to solve such problems efficiently using ordinary > signaling. You *very seldom* need to resort to usage of priority messages. > Receiving processes have *not* been optimized for handling large amounts of > priority messages. If a process accumulates a large amount of priority > messages, the design of that message protocol should be redesigned since > this is not how priority messages are intended to be used. A process can enable priority message reception by creating a *priority process alias* or shorter *priority alias*. Such an alias is created by calling the `erlang:alias/1` BIF with the `priority` option. This priority alias then needs to be distributed to processes that are to be able to send priority messages to the process that created the alias. In order to send a priority message, the priority alias should be passed to the `erlang:send/3` BIF at the same time as the option `priority` is passed in the option list. Note that both the priority alias and the `priority` option need to be passed in order for the message to be accepted as a priority message. The priority alias can also be used for sending exit signals which will be handled as priority messages if the receiver is trapping exits. In this case the priority alias should be passed as the first argument to the `erlang:exit/3` BIF and the option `priority` should be passed in the option list. Also in this case both the priority alias and the `priority` option need to be passed in order for the message to be accepted as a priority message. Note that this *only* affects how a potential exit message is handled if the receiver is trapping exits. The exit signal as such will not get a higher priority. If the creator of the priority alias deactivates the alias, the signals sent using the alias will be dropped the same way as for any [process alias](ref_man_processes.md#process-aliases). Priority message reception can also be enabled for exit signals due to broken links and messages triggered due to monitors. Since these signals are not sent when a process calls a specific function for sending a signal, but instead are sent when specific events occur in the system, a priority alias cannot be used for this. In order to enable priority message reception of messages triggered by a monitor, the process that creates the monitor needs to create it using the `erlang:monitor/3` BIF and pass the option `priority`. A message received due to the monitor being triggered will then be handled as a priority message. In order to enable priority message reception for exit signals due to broken links, the process that wants the exit signal as a priority message needs to call the `erlang:link/2` BIF with the `priority` option. The `priority` option will only enable priority message handling of exit signals for the process that called the `erlang:link/2` BIF with the `priority` option. Also in this case, this *only* affects how a potential exit message is handled if the receiver is trapping exits. [](){: #visible-resources } ### Directly Visible Erlang Resources As described earlier, `exit` signals due to links, `down` signals, and reply signals from an exiting process due to `alive_request`s are not sent until all _directly visible Erlang resources_ held by the terminating process have been released. With _directly visible Erlang resources_ we here mean all resources made available by the language excluding resources held by heap data, dirty native code execution, and the process identifier of the terminating process. Examples of _directly visible Erlang resources_ are [registered name](ref_man_processes.md#registered-processes) and [ETS](`m:ets`) tables. #### The Excluded Resources The process identifier of the process cannot be released for reuse until everything regarding the process has been released. A process executing dirty native code in a NIF when it receives an exit signal will be set into an exiting state even if it is still executing dirty native code. _Directly visible Erlang resources_ will be released, but the runtime system cannot force the native code to stop executing. The runtime system tries to prevent the execution of the dirty native code from affecting other processes by, for example, disabling functionality such as [`enif_send()`](`e:erts:erl_nif.md#enif_send`) when used from a terminated process, but if the NIF is not well-behaved it can still affect other processes. A well-behaved dirty NIF should test if [the process it is executing in has exited](`e:erts:erl_nif.md#enif_is_current_process_alive`), and if so stop executing. In the general case, the heap of a process cannot be removed before all signals that it needs to send have been sent. Resources held by heap data are the memory blocks containing the heap, but also include things referred to from the heap such as off-heap binaries, and resources held via NIF [resource objects](`e:erts:erl_nif.md#resource_objects`) on the heap. [](){: #signal-delivery } ### Delivery of Signals The amount of time that passes between the time 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`. Note that `S1` may or may not have been lost. [](){: #signal-irregularities } ### Irregularities - **Synchronous Error Checking** - Some functionality that sends signals has synchronous error checking when sending locally on a node and fails if the receiver is not present at the time when the signal is sent: - The [send operator (`!`)](expressions.md#send), [`erlang:send/2,3`](`erlang:send/2`), BIFs and [`erlang:send_nosuspend/2,3`](`erlang:send_nosuspend/2`) BIFs when the receiver is identified by a name that is expected to be registered locally. - `erlang:link/1` - `erlang:group_leader/2` - **Unexpected Behaviours of Exit Signals** - When an [`exit` signal with exit reason `kill` is received](ref_man_processes.md#receiving_exit_signals), the action taken is different depending on whether the signal was sent due to a linked process terminating, or the signal was explicitly sent using the [`exit_signal/2`](`erlang:exit_signal/2`) BIF. When sent using the [`exit_signal/2`](`exit_signal/2`) BIF, the signal cannot be [trapped](`m:erlang#process_flag_trap_exit`), while it can be trapped if the signal was sent due to a link. - **Blocking Signaling Over Distribution[](){: #blocking-signaling-over-distribution } ** When sending a signal over a distribution channel, the sending process may be suspended even though the signal is supposed to be sent asynchronously. This is due to the built-in flow control over the channel that has been present more or less forever. When the size of the output buffer for the channel reaches the _distribution buffer busy limit_, processes sending on the channel will be suspended until the size of the buffer shrinks below the limit. Depending on the reason for why the buffer got full, the time it takes before suspended processes are resumed can vary _very much_. A consequence of this can, for example, be that a timeout in a call to [erpc:call()](`erpc:call/5`) is significantly delayed. Since this functionality has been present for so long, it is not possible to remove it, but it is possible to enable _fully asynchronous distributed signaling_ on a per-process level using [`process_flag(async_dist, Bool)`](`m:erlang#process_flag_async_dist`) which can be used to solve problems occurring due to blocking signaling. However, note that you need to make sure that flow control for data sent using _fully asynchronous distributed signaling_ is implemented, or that the amount of such data is known to always be limited; otherwise, you may get into a situation with excessive memory usage. The size of the _distribution buffer busy limit_ can be inspected by calling [`erlang:system_info(dist_buf_busy_limit)`](`m:erlang#system_info_dist_buf_busy_limit`). The irregularities mentioned earlier cannot be fixed as they have been part of Erlang too long and it would break a lot of existing code. ## Links Two processes can be _linked_ to each other. Also, a process and a port that reside on the same node can be linked to each other. A link between two processes can be created if one of them calls the [`link/1`](`erlang:link/1`) BIF with the process identifier of the other process as argument. Links can also be created using one of the following spawn BIFs [`spawn_link()`](`erlang:spawn_link/4`), [`spawn_opt()`](`erlang:spawn_opt/5`), or [`spawn_request()`](`erlang:spawn_request/5`). The spawn operation and the link operation will be performed atomically in these cases. If one of the participants of a link terminates, it will [send an exit signal](ref_man_processes.md#sending_exit_signals) to the other participant. The exit signal will contain the [exit reason](ref_man_processes.md#link_exit_signal_reason) of the terminated participant. A link can be removed by calling the [`unlink/1`](`erlang:unlink/1`) BIF. Links are bidirectional and there can only be one link between two processes. Repeated calls to `link()` have no effect. Either one of the involved processes may create or remove a link. Links are used to monitor the behavior of other processes, see [Error Handling](ref_man_processes.md#errors). [](){: #errors } ## Error Handling Erlang has a built-in feature for error handling between processes. Terminating processes emit exit signals to all linked processes, which can terminate as well or handle the exit in some way. This feature can be used to build hierarchical program structures where some processes are supervising other processes, for example, restarting them if they terminate abnormally. See [OTP Design Principles](`e:system:design_principles.md`) for more information about OTP supervision trees, which use this feature. [](){: #sending_exit_signals } ### Sending Exit Signals When a process or port [terminates](ref_man_processes.md#process-termination), it will send exit signals to all processes and ports that it is [linked](ref_man_processes.md#links) to. The exit signal will contain the following information: - **Sender identifier** - The process or port identifier of the process or port that terminated. - **Receiver identifier** - The process or port identifier of the process or port which the exit signal is sent to. - **The `link` flag** - This flag will be set indicating that the exit signal was sent due to a link. - **[](){: #link_exit_signal_reason } Exit reason** The exit reason of the process or port that terminated or the atom: - `noproc` in case no process or port was found when setting up a link in a preceding call to the [`link(PidOrPort)`](`erlang:link/1`) BIF. The process or port identified as sender of the exit signal will equal the `PidOrPort` argument passed to [`link/1`](`link/1`). - `noconnection` in case the linked processes reside on different nodes and the connection between the nodes was lost or could not be established. The process or port identified as sender of the exit signal might in this case still be alive. Exit signals can also be sent explicitly by calling the [`exit_signal(PidOrPort, Reason)`](`erlang:exit_signal/2`) BIF. The exit signal is sent to the process or port identified by the `PidOrPort` argument. The exit signal sent will contain the following information: - **Sender identifier** - The process identifier of the process that called [`exit_signal/2`](`exit_signal/2`). - **Receiver identifier** - The process or port identifier of the process or port which the exit signal is sent to. - **The `link` flag** - This flag will not be set, indicating that this exit signal was not sent due to a link. - **Exit reason** - The term passed as `Reason` in the call to [`exit_signal/2`](`exit_signal/2`). If `Reason` is the atom `kill`, the receiver cannot [trap the exit](`m:erlang#process_flag_trap_exit`) signal and will unconditionally terminate when it receives the signal. [](){: #receiving_exit_signals } ### Receiving Exit Signals What happens when a process receives an exit signal depends on: - The [trap exit](`m:erlang#process_flag_trap_exit`) state of the receiver at the time when the exit signal is received. - The exit reason of the exit signal. - The sender of the exit signal. - The state of the `link` flag of the exit signal. If the `link` flag is set, the exit signal was sent due to a link; otherwise, the exit signal was sent by a call to the [`exit_signal/2`](`erlang:exit_signal/2`) BIF. - If the `link` flag is set, what happens also depends on whether the [link is still active or not](`erlang:unlink/1`) when the exit signal is received. Based on the above states, the following will happen when an exit signal is received by a process: - The exit signal is silently dropped if: - the `link` flag of the exit signal is set and the corresponding link has been deactivated. - the exit reason of the exit signal is the atom `normal`, and the receiver is not trapping exits. - The receiving process is terminated if: - the `link` flag of the exit signal is not set, and the exit reason of the exit signal is the atom `kill`. The receiving process will terminate with the atom `killed` as exit reason. - the receiver is not trapping exits, and the exit reason is something other than the atom `normal`. Also, if the `link` flag of the exit signal is set, the link also needs to be active; otherwise, the exit signal will be dropped. The exit reason of the receiving process will equal the exit reason of the exit signal. Note that if the `link` flag is set, an exit reason of `kill` will _not_ be converted to `killed`. - The exit signal is converted to a message signal and added to the end of the message queue of the receiver, if the receiver is trapping exits, the `link` flag of the exit signal is: - not set, and the exit reason of the signal is not the atom `kill`. - set, and the corresponding link is active. Note that an exit reason of `kill` will _not_ terminate the process in this case and it will not be converted to `killed`. The converted message will be of the form `{'EXIT', SenderID, Reason}` where `Reason` equals the exit reason of the exit signal and `SenderID` is the identifier of the process or port that sent the exit signal. ## Monitors An alternative to links are _monitors_. A process `Pid1` can create a monitor for `Pid2` by calling the BIF [`erlang:monitor(process, Pid2)`](`erlang:monitor/2`). The function returns a reference `Ref`. If `Pid2` terminates with exit reason `Reason`, a 'DOWN' message is sent to `Pid1`: ```text {'DOWN', Ref, process, Pid2, Reason} ``` If `Pid2` does not exist, the 'DOWN' message is sent immediately with `Reason` set to `noproc`. Monitors are unidirectional. Repeated calls to `erlang:monitor(process, Pid)` create several independent monitors, and each one sends a 'DOWN' message when `Pid` terminates. A monitor can be removed by calling [`erlang:demonitor(Ref)`](`erlang:demonitor/1`). Monitors can be created for processes with registered names, also at other nodes. ## Process Dictionary Each process has its own process dictionary, accessed by calling the following BIFs: - [`put(Key, Value)`](`erlang:put/2`) - [`get(Key)`](`erlang:get/1`) - [`get()`](`erlang:get/0`) - [`get_keys(Value)`](`erlang:get_keys/1`) - [`erase(Key)`](`erlang:erase/1`) - [`erase()`](`erlang:erase/0`)