proc_lib(3)

📦
version 29.0.6 · 3 versions
, in ubuntu stonking

🎀 proc_lib(3) — Erlang Module Definition 🎀

okay bestie, this is the <pink>proc_lib</pink> manual page for Erlang. It's giving async AND sync process-starting realness, OTP-style. Let's get into it. 💖

✨ NAME ✨

proc_lib — Functions for asynchronous and synchronous start of processes adhering to the OTP design principles.

🌸 DESCRIPTION 🌸

okay so proc_lib is the module you use to start processes that actually follow the OTP Design Principles. The OTP standard behaviors — for example, gen_server and gen_statem — literally use these functions when they start new processes. You can also use them to start special processes: user-defined processes that comply to the OTP design principles. Need an example? Go see the section sys and proc_lib in OTP Design Principles. 💅

When a process starts, some useful info gets initialized. The registered names, or the process identifiers, of the parent process — plus the parent ancestors — are stored together with information about the function initially called in the process. ✨

In "plain Erlang", a process is said to terminate normally only for exit reason normal. But a process started using proc_lib is also said to terminate normally if it exits with reason shutdown or {shutdown,Term}. And shutdown is the reason used when an application (supervision tree) is stopped. periodt.

When a process started using proc_lib terminates abnormally — that is, with another exit reason than normal, shutdown, or {shutdown,Term} — a crash report is generated. That report gets written to the terminal by the default logger handler setup by Kernel. For more information about how crash reports were logged prior to Erlang/OTP 21.0, see SASL Error Logging in the SASL User's Guide. 📝

Unlike in "plain Erlang", proc_lib processes will not generate error reports, which are written to the terminal by the emulator. All exceptions are converted to exits which are ignored by the default logger handler. no cap.

The crash report contains the previously stored information, such as ancestors and initial function, the termination reason, and information about other processes that terminate as a result of this process terminating. it's giving receipts. 🧾

See Also 💫

logger

🦋 DATA TYPES 🦋

dict_or_pid()

dict_or_pid() ::
          pid() |
          (ProcInfo :: [_]) |
          {X :: integer(), Y :: integer(), Z :: integer()}.

exception()

exception() ::
          {Class :: error | exit | throw, Reason :: term()} |
          {Class :: error | exit | throw,
           Reason :: term(),
           Stacktrace :: erlang:raise_stacktrace()}.

An exception passed to init_fail/3. See erlang:raise/3 for a description of Class, Reason and Stacktrace. 🫶

spawn_option()

spawn_option() :: erlang:spawn_opt_option().

Equivalent to erlang:spawn_opt_option/0. 💖

start_spawn_option()

start_spawn_option() ::
          link |
          {priority, erlang:priority_level()} |
          {fullsweep_after, non_neg_integer()} |
          {min_heap_size, non_neg_integer()} |
          {min_bin_vheap_size, non_neg_integer()} |
          {max_heap_size, erlang:max_heap_size()} |
          {message_queue_data, erlang:message_queue_data()}.

A restricted set of spawn options. Most notably monitor is not part of these options. 💅

🔥 FUNCTIONS 🔥

format/1 🌟

format(CrashReport) -> string() when CrashReport :: [term()].

Equivalent to format(CrashReport, latin1). ✨

format/2 🌟

format(CrashReport, Encoding) -> string()
                when
                    CrashReport :: [term()],
                    Encoding :: latin1 | unicode | utf8.
NOTE: This function is deprecated in the sense that the error_logger is no longer the preferred interface for logging in Erlang/OTP. A new logging API was added in Erlang/OTP 21.0, but legacy error_logger handlers can still be used. New Logger handlers do not need to use this function, since the formatting callback (report_cb) is included as metadata in the log event.

This function can be used by a user-defined legacy error_logger event handler to format a crash report. The crash report is sent using logger, and the event to be handled is of the format {error_report, GL, {Pid, crash_report, CrashReport}}, where GL is the group leader pid of process Pid that sent the crash report. 🫶

format/3 🌟

format(CrashReport, Encoding, Depth) -> string()
                when
                    CrashReport :: [term()],
                    Encoding :: latin1 | unicode | utf8,
                    Depth :: unlimited | pos_integer().
NOTE: This function is deprecated in the sense that the error_logger is no longer the preferred interface for logging in Erlang/OTP. A new logging API was added in Erlang/OTP 21.0, but legacy error_logger handlers can still be used. New Logger handlers do not need to used this function, since the formatting callback (report_cb) is included as metadata in the log event.

This function can be used by a user-defined legacy error_logger event handler to format a crash report. When Depth is specified as a positive integer, it is used in the format string to limit the output as follows: io_lib:format("~P", [Term,Depth]). 💅

get_label/1 🌟

get_label(Pid) -> undefined | term() when Pid :: pid().

Returns either undefined or the label for the process Pid set with proc_lib:set_label/1. 🏷️

hibernate/3 🌟

hibernate(Module, Function, Args) -> no_return()
                    when
                        Module :: module(),
                        Function :: atom(),
                        Args :: [term()].

This function does the same as (and does call) the hibernate/3 BIF, but ensures that exception handling and logging continues to work as expected when the process wakes up. 😴

Always use this function instead of the BIF for processes started using proc_lib functions. 🔥

init_ack/1 🌟

init_ack(Ret) -> ok when Ret :: term().

Equivalent to init_ack(Parent, Ret) where Parent is the process that called start/5. ✅

init_ack/2 🌟

init_ack(Parent, Ret) -> ok when Parent :: pid(), Ret :: term().

This function must only be used by a process that has been started by a start[_link|_monitor]/3,4,5 function. It tells Parent that the process has initialized itself and started. 🫡

Function init_ack/1 uses the parent value previously stored by the start function used.

If neither this function nor init_fail/2,3 is called by the started process, the start function returns an error tuple when the started process exits, or when the start function time-out (if used) has passed, see start/3,4,5.

WARNING: Do not use this function to return an error indicating that the process start failed. When doing so the start function can return before the failing process has exited, which may block VM resources required for a new start attempt to succeed. Use init_fail/2,3 for that purpose. 🚨

The following example illustrates how this function and proc_lib:start_link/3 are used:

-module(my_proc).
-export([start_link/0]).
-export([init/1]).

start_link() ->
    proc_lib:start_link(my_proc, init, [self()]).

init(Parent) ->
    case do_initialization() of
        ok ->
            proc_lib:init_ack(Parent, {ok, self()});
        {error, Reason} ->
            exit(Reason)
    end,
    loop().

init_fail/2 🌟

init_fail(Return :: term(), Exception :: exception()) ->
                    no_return().

Equivalent to init_fail(Parent, Return, Exception) where Parent is the process that called start/5. 💔

init_fail/3 🌟

init_fail(Parent :: pid(),
                 Return :: term(),
                 Exception :: exception()) ->
                    no_return().

This function must only be used by a process that has been started by a start[_link|_monitor]/3,4,5 function. It tells Parent that the process has failed to initialize, and immediately raises an exception according to Exception. The start function then returns Ret. 💥

See erlang:raise/3 for a description of Class, Reason and Stacktrace.

WARNING: Do not consider catching the exception from this function. That would defeat its purpose. A process started by a start[_link|_monitor]/3,4,5 function should end in a value (that will be ignored) or an exception that will be handled by this module. See Description. 🚨

If neither this function nor init_ack/1,2 is called by the started process, the start function returns an error tuple when the started process exits, or when the start function time-out (if used) has passed, see start/3,4,5.

The following example illustrates how this function and proc_lib:start_link/3 can be used:

-module(my_proc).
-export([start_link/0]).
-export([init/1]).

start_link() ->
    proc_lib:start_link(my_proc, init, [self()]).

init(Parent) ->
    case do_initialization() of
        ok ->
            proc_lib:init_ack(Parent, {ok, self()});
        {error, Reason} = Error ->
            proc_lib:init_fail(Parent, Error, {exit, normal})
    end,
    loop().

initial_call/1 🌟

initial_call(Process) -> {Module, Function, Args} | false
                      when
                          Process :: dict_or_pid(),
                          Module :: module(),
                          Function :: atom(),
                          Args :: [atom()].

Extracts the initial call of a process that was started using one of the spawn or start functions in this module. Process can either be a pid, an integer tuple (from which a pid can be created), or the process information of a process Pid fetched through an erlang:process_info(Pid) function call. 🔍

okay bestie, we’re still deep in the initial_call/1 lore, so let’s finish that thought before we move on 💅

⚠️ NOTE: the Args list doesn’t contain the actual arguments anymore — it contains the same number of atoms as the number of arguments. The first atom is 'Argument__1', the second is 'Argument__2', and so on, periodt. Why? because the argument list could waste a significant amount of memory, and if the argument list contained funs, it could be impossible to upgrade the code for the module. 😭

If the process was spawned using a fun, initial_call/1 no longer returns the fun. Instead it returns the module, the function for the local function implementing the fun, and the arity. For example, {some_module,-work/3-fun-0-,0} — which means the fun was created in function some_module:work/3. The reason is that keeping the fun would prevent code upgrade for the module, and a significant amount of memory could be wasted. slay for memory safety, honestly 🧚

✨ set_label(Label) -> ok ✨

set_label(Label) -> ok
when
    Label :: term().

Set a label for the current process. The main character purpose here is to help with debugging unregistered processes. The process label can be used in tools and crash reports to identify processes, but it doesn’t have to be unique or an atom the way a registered name needs to be. The process label can be any term, for example {worker_process, 1..N}. 🏷️

Use proc_lib:get_label/1 to look up the process description.

✨ spawn(Node, Module, Function, Args) -> pid() ✨

spawn(Node, Module, Function, Args) -> pid()
    when
        Node :: node(),
        Module :: module(),
        Function :: atom(),
        Args :: [term()].

Spawns a new process and initializes it as described at the beginning of this manual page. The process is spawned using the spawn BIFs. 🐣

spawn_link(Node, Module, Function, Args) -> pid()
    when
        Node :: node(),
        Module :: module(),
        Function :: atom(),
        Args :: [term()].

Spawns a new process and initializes it as described at the beginning of this manual page. The process is spawned using the spawn_link BIFs. 🔗

✨ spawn_opt(Node, Module, Function, Args, SpawnOpts) -> pid() | {pid(), reference()} ✨

spawn_opt(Node, Module, Function, Args, SpawnOpts) ->
              pid() | {pid(), reference()}
              when
                  Node :: node(),
                  Module :: module(),
                  Function :: atom(),
                  Args :: [term()],
                  SpawnOpts :: [erlang:spawn_opt_option()].

Spawns a new process and initializes it as described at the beginning of this manual page. The process is spawned using the erlang:spawn_opt BIFs. 🎛️

✨ start(Module, Function, Args, Time, SpawnOpts) -> Ret ✨

start(Module, Function, Args, Time, SpawnOpts) -> Ret
    when
        Module :: module(),
        Function :: atom(),
        Args :: [term()],
        Time :: timeout(),
        SpawnOpts :: [start_spawn_option()],
        Ret :: term() | {error, Reason :: term()}.

Starts a new process synchronously. It spawns the process and waits for it to start. ⏳

To indicate a successful start, the started process must call init_ack(Parent, Ret) where Parent is the process that evaluates this function, or init_ack(Ret). Ret is then returned by this function. 🫶

If the process fails to start, it must fail — preferably by calling init_fail(Parent, Ret, Exception) where Parent is the process that evaluates this function, or init_fail(Ret, Exception). Ret is then returned by this function, and the started process fails with Exception. 💀

If the process instead fails before calling init_ack/1,2 or init_fail/2,3, this function returns {error, Reason} where Reason depends a bit on the exception, just like for a process link {'EXIT',Pid,Reason} message. 😭

If Time is specified as an integer, this function waits for Time milliseconds for the new process to call init_ack/1,2 or init_fail/2,3. Otherwise the process gets killed and Ret = {error, timeout} is returned. ⌛

Argument SpawnOpts, if specified, is passed as the last argument to the spawn_opt/4 BIF.

⚠️ NOTE: Using spawn option monitor is not allowed. It causes the function to fail with reason badarg. Using spawn option link will set a link to the spawned process, just like start_link/3,4,5. 🔥
start_link(Module, Function, Args, Time, SpawnOpts) -> Ret
    when
        Module :: module(),
        Function :: atom(),
        Args :: [term()],
        Time :: timeout(),
        SpawnOpts :: [start_spawn_option()],
        Ret :: term() | {error, Reason :: term()}.

Starts a new process synchronously. It spawns the process and waits for it to start. A link is atomically set on the newly spawned process. 🔗✨

⚠️ NOTE: If the started process gets killed or crashes with a reason that is not normal, the process link will kill the calling process, so this function does not return — unless the calling process traps exits. For example, if this function times out it will kill the spawned process, and then the link might kill the calling process. 💀

Besides setting a link on the spawned process, this function behaves like start/5.

When the calling process traps exits: if this function returns due to the spawned process exiting (any error return), this function receives (consumes) the 'EXIT' message — also when this function times out and kills the spawned process. 👑

⚠️ NOTE: Using spawn option monitor is not allowed. It causes the function to fail with reason badarg. 🚫

✨ start_monitor(Module, Function, Args, Time, SpawnOpts) -> {Ret, Mon} ✨

start_monitor(Module, Function, Args, Time, SpawnOpts) ->
                              {Ret, Mon}
                              when
                                  Module :: module(),
                                  Function :: atom(),
                                  Args :: [term()],
                                  Time :: timeout(),
                                  SpawnOpts :: [start_spawn_option()],
                                  Mon :: reference(),
                                  Ret :: term() | {error, Reason :: term()}.

Starts a new process synchronously. It spawns the process and waits for it to start. A monitor is atomically set on the newly spawned process. 👀💖

Besides setting a monitor on the spawned process, this function behaves like start/5.

The return value is {Ret, Mon} where Ret corresponds to the Ret argument in the call to init_ack/1,2 or init_fail/2,3, and Mon is the monitor reference of the monitor that has been set up. 🎀

If this function returns due to the spawned process exiting — that is, returns any error value — a 'DOWN' message will be delivered to the calling process, also when this function times out and kills the spawned process. 😵‍💫

⚠️ NOTE: Using spawn option monitor is not allowed. It causes the function to fail with reason badarg. Using spawn option link will set a link to the spawned process, just like start_link/3,4,5. 🔥

✨ stop(Process) -> ok ✨

stop(Process) -> ok
    when
        Process :: pid() | RegName | {RegName, node()},
        RegName :: atom().

Equivalent to stop(Process, normal, infinity). ✋

✨ stop(Process, Reason, Timeout) -> ok ✨

stop(Process, Reason, Timeout) -> ok
    when
        Process :: pid() | RegName | {RegName, node()},
        RegName :: atom(),
        Reason :: term(),
        Timeout :: timeout().

Orders the process to exit with the specified Reason and waits for it to terminate.

Returns ok if the process exits with the specified Reason within Timeout milliseconds.

If the call times out, a timeout exception is raised.

If the process does not exist, a noproc exception is raised.

The implementation of this function is based on the terminate system message, and requires that the process handles system messages correctly. For information about system messages, see sys and section sys and proc_lib in OTP Design Principles. 📚

✨ translate_initial_call(Process) -> {Module, Function, Arity} ✨

translate_initial_call(Process) -> {Module, Function, Arity}
    when
        Process :: dict_or_pid(),
        Module :: module(),
        Function :: atom(),
        Arity :: byte().

This function is used by functions \c:i/0 and \c:regs/0 to present process information. 🧠✨

This function extracts the initial call of a process that was started using one of the spawn or start functions in this module, and translates it to more useful information. Process can either be a pid, an integer tuple (from which a pid can be created), or the process information of a process Pid fetched through an erlang:process_info(Pid) function call. 🔍

If the initial call is to one of the system-defined behaviors such as gen_server or gen_event, it is translated to more useful information. If a gen_server is spawned, the returned Module is the name of the callback module and Function is init (the function that initiates the new server). 👑

A supervisor and a supervisor_bridge are also gen_server processes. To return information that this process is a supervisor and the name of the callback module, Module is supervisor and Function is the name of the supervisor callback module. Arity is 1, as the init/1 function is called initially in the callback module. 🌈

By default, {proc_lib,init_p,5} is returned if no information about the initial call can be found. It is assumed that the caller knows that the process has been spawned with the proc_lib module. 💖

that’s the whole vibe, bestie — signed off with love from Ericsson AB, stdlib 8.0.4, proc_lib(3) 🎀💅✨

📦 where this page comes from