pg2(3)

MODULE
pg2 - Distributed Named Process Groups

DESCRIPTION

This module implements process groups. The groups in this module differ from the groups in the module pg in several ways. In pg, each message is sent to all members in the group. In this module, each message may be sent to one, some, or all members.

A group of processes can be accessed by a common name. For example, if there is a group named foobar, there can be a set of processes (which can be located on different nodes) which are all members of the group foobar. There is no special functions for sending a message to the group. Instead, client functions should be written with the functions get_members/1 and get_local_members/1 to find out which process are members of the group. Then the message can be sent to one or more members of the group.

If a member terminates, it is automatically removed from the group.

  Warning:

This module is used by the disk_log module for managing distributed disk logs. The disk log names are used as group names, which means that some action may need to be taken to avoid name clashes.

EXPORTS

create(Name) -> void()

    Types
        Name = term()

    Creates a new, empty process group. The group is globally visible on all nodes. If the group exists, nothing happens.

delete(Name) -> void()

    Types
        Name = term()

    Deletes a process group.

get_closest_pid(Name) -> Pid | {error, Reason}

    Types
        Name = term()

    This is a useful dispatch function which can be used from client functions. It returns a process on the local node, if such a process exist. Otherwise, it chooses one randomly.

get_members(Name) -> [Pid] | {error, Reason}

    Types
        Name = term()

    Returns all processes in the group Name. This function should be used from within a client function that accesses the group. It is then optimized for speed.

get_local_members(Name) -> [Pid] | {error, Reason}

    Types
        Name = term()

    Returns all processes running on the local node in the group Name. This function should to be used from within a client function that accesses the group. It is then optimized for speed.

join(Name, Pid) -> ok | {error, Reason}

    Types
        Name = term()

    Joins the process Pid to the group Name.

leave(Name, Pid) -> ok | {error, Reason}

    Types
        Name = term()

    Makes the process Pid leave the group Name.

which_groups() -> [Name]

    Types
        Name = term()

    Returns a list of all known groups.

start()
start_link() -> {ok, Pid} | {error, Reason}

    Starts the pg2 server. Normally, the server does not need to be started explicitly, as it is started dynamically if it is needed. This is useful during development, but in a target system the server should be started explicitly. Use configuration parameters for kernel for this.

SEE ALSO

kernel(6), pg(3)