Conveniences for working with processes and the process dictionary.
Besides the functions available in this module, the Kernel module
exposes and auto-imports some basic functionality related to processes
available through the following functions:
While this module provides low-level conveniences to work with processes,
developers typically use abstractions such as Agent, GenServer,
Registry, Supervisor and Task for building their systems and
resort to this module for gathering information, trapping exits, links
and monitoring.
Aliases
Aliases are a feature introduced in Erlang/OTP 24. An alias is a way
to refer to a PID in order to send messages to it. The advantage of using
aliases is that they can be deactivated even if the aliased process is still
running. If you send a message to a deactivated alias, nothing will happen.
This makes request/response scenarios easier to implement.
You can use alias/0 or alias/1 to set an alias, and then you can send
messages to that alias like you do with PIDs using send/2. To deactivate
an alias, you can use unalias/1. If you send a message to a deactivated alias,
nothing will happen.
For example, you could have a process that listens for :ping messages:
If now you deactivate the source_alias and ping the server again, you
won't receive any response since the server will send/2 the :pong response
to a deactivated alias.
A remote or local PID, a local port, a locally registered name, or a tuple in
the form of {registered_name, node} for a registered name at another node.
Tells whether the given process is alive on the local node.
If the process identified by pid is alive (that is, it's not exiting and has
not exited yet) then this function returns true. Otherwise, it returns
false.
pid must refer to a process running on the local node or ArgumentError is raised.
To check whether a process on any node is alive you can use the :erpc module.
When the result is an integer, it represents the time in milliseconds
left until the timer would have expired.
When the result is false, a timer corresponding to timer_ref could not be
found. This can happen either because the timer expired, because it has
already been canceled, or because timer_ref never corresponded to a timer.
Even if the timer had expired and the message was sent, this function does not
tell you if the timeout message has arrived at its destination yet.
Inlined by the compiler.
Options
:async - (boolean) when false, the request for cancellation is
synchronous. When true, the request for cancellation is asynchronous,
meaning that the request to cancel the timer is issued and :ok is
returned right away. Defaults to false.
:info - (boolean) whether to return information about the timer being
cancelled. When the :async option is false and :info is true, then
either an integer or false (like described above) is returned. If
:async is false and :info is false, :ok is returned. If :async
is true and :info is true, a message in the form {:cancel_timer, timer_ref, result} (where result is an integer or false like
described above) is sent to the caller of this function when the
cancellation has been performed. If :async is true and :info is
false, no message is sent. Defaults to true.
Demonitors the monitor identified by the given reference.
If monitor_ref is a reference which the calling process
obtained by calling monitor/1, that monitoring is turned off.
If the monitoring is already turned off, nothing happens.
Sends an exit signal with the given reason to pid.
Exit behavior differs based on the value of reason:
If :normal, pid will not exit unless it is the calling process, in
which case it will exit with the reason :normal. If it is trapping exits,
the exit signal is transformed into a message {:EXIT, from, :normal} and
delivered to its message queue.
If :kill, which occurs when Process.exit(pid, :kill) is called, an
untrappable exit signal is sent to pid which will unconditionally exit
with reason :killed.
If any other term and pid is not trapping exits, pid will exit with
the given reason.
If any other term and pid is trapping exits, the exit signal is
transformed into a message {:EXIT, from, reason} and delivered to its
message queue.
The functions Kernel.exit/1 and Process.exit/2 are
named similarly but provide very different functionalities. The
Kernel:exit/1 function should be used when the intent is to stop the current
process while Process.exit/2 should be used when the intent is to send an
exit signal to another process. Note also that Kernel.exit/1 can be caught
with try/1 while Process.exit/2 can only be handled by trapping exits and
when the signal is different than :kill.
Puts the calling process into a "hibernation" state.
The calling process is put into a waiting state
where its memory allocation has been reduced as much as possible,
which is useful if the process does not expect to receive any messages
in the near future.
Creates a link between the calling process and the given item (process or
port).
Links are bidirectional. Linked processes can be unlinked by using unlink/1.
If such a link exists already, this function does nothing since there can only
be one link between two given processes. If a process tries to create a link
to itself, nothing will happen.
When two processes are linked, each one receives exit signals from the other
(see also exit/2). Let's assume pid1 and pid2 are linked. If pid2
exits with a reason other than :normal (which is also the exit reason used
when a process finishes its job) and pid1 is not trapping exits (see
flag/2), then pid1 will exit with the same reason as pid2 and in turn
emit an exit signal to all its other linked processes. The behavior when
pid1 is trapping exits is described in exit/2.
Returns a list of PIDs corresponding to all the
processes currently existing on the local node.
Note that if a process is exiting, it is considered to exist but not be
alive. This means that for such process, alive?/1 will return false but
its PID will be part of the list of PIDs returned by this function.
Starts monitoring the given item from the calling process.
This function is similar to monitor/1, but accepts options to customize how
item is monitored. See :erlang.monitor/3 for documentation on those
options.
When the result is an integer, it represents the time in milliseconds
left until the timer will expire.
When the result is false, a timer corresponding to timer_ref could not be
found. This can be either because the timer expired, because it has already
been canceled, or because timer_ref never corresponded to a timer.
Even if the timer had expired and the message was sent, this function does not
tell you if the timeout message has arrived at its destination yet.
dest may be a remote or local PID, a local port, a locally
registered name, or a tuple in the form of {registered_name, node} for a
registered name at another node.
Inlined by the compiler.
Options
:noconnect - when used, if sending the message would require an
auto-connection to another node the message is not sent and :noconnect is
returned.
:nosuspend - when used, if sending the message would cause the sender to
be suspended the message is not sent and :nosuspend is returned.
Otherwise the message is sent and :ok is returned.
If dest is a PID, it must be the PID of a local process, dead or alive.
If dest is an atom, it must be the name of a registered process
which is looked up at the time of delivery. No error is produced if the name does
not refer to a process.
The message is not sent immediately. Therefore, dest can receive other messages
in-between even when time is 0.
This function returns a timer reference, which can be read with read_timer/1
or canceled with cancel_timer/1.
The timer will be automatically canceled if the given dest is a PID
which is not alive or when the given PID exits. Note that timers will not be
automatically canceled when dest is an atom (as the atom resolution is done
on delivery).
Options
:abs - (boolean) when false, time is treated as relative to the
current monotonic time. When true, time is the absolute value of the
Erlang monotonic time at which msg should be delivered to dest.
To read more about Erlang monotonic time and other time-related concepts,
look at the documentation for the System module. Defaults to false.
The term does not need to be unique, and will be shown in Observer and in
crash logs.
This label may be useful for identifying a process as one of multiple in a
given role, such as :queue_worker or {:live_chat, user_id}.
timeout is either the number of milliseconds to sleep as an
integer or the atom :infinity. When :infinity is given,
the current process will sleep forever, and not
consume or reply to messages.
Sleeping limit
Before Elixir v1.18, sleep/1 did not accept integer timeout values greater
than 16#ffffffff, that is, 2^32-1. Since Elixir v1.18, arbitrarily-high integer
values are accepted.
Use this function with extreme care. For almost all situations
where you would use sleep/1 in Elixir, there is likely a
more correct, faster and precise way of achieving the same with
message passing.
For example, if you are waiting for a process to perform some
action, it is better to communicate the progress of such action
with messages.
In other words, do not:
Task.start_link(fn->do_something()...end)# Wait until work is doneProcess.sleep(2000)
Spawns the given function according to the given options.
The result depends on the given options. In particular,
if :monitor is given as an option, it will return a tuple
containing the PID and the monitoring reference, otherwise
just the spawned process PID.
More options are available; for the comprehensive list of available options
check :erlang.spawn_opt/4.
Spawns the given function fun from module mod, passing the given args
according to the given options.
The result depends on the given options. In particular,
if :monitor is given as an option, it will return a tuple
containing the PID and the monitoring reference, otherwise
just the spawned process PID.
It also accepts extra options, for the list of available options
check :erlang.spawn_opt/4.
Removes the link between the calling process and the given item (process or
port).
If there is no such link, this function does nothing. If pid_or_port does
not exist, this function does not produce any errors and simply does nothing.
You are visitor 01402503 — GeezerVison does not store the pages you look up. Best viewed with Netscape Navigator 4.7 or Internet Explorer 6 at 800×600. No cookies required.