Linux and UNIX Man Pages

Linux & Unix Commands - Search Man Pages

pg2(3erl) [linux man page]

pg2(3erl)						     Erlang Module Definition							 pg2(3erl)

NAME
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 mes- sage 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 are 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 pro- cesses 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() Pid = pid() Reason = {no_process, Name} | {no_such_group, Name} 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() Pid = pid() Reason = {no_such_group, Name} Returns all processes in the group Name . This function should be used from within a client function that accesses the group. It is therefore optimized for speed. get_local_members(Name) -> [Pid] | {error, Reason} Types Name = term() Pid = pid() Reason = {no_such_group, Name} 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 therefore optimized for speed. join(Name, Pid) -> ok | {error, Reason} Types Name = term() Pid = pid() Reason = {no_such_group, Name} Joins the process Pid to the group Name . A process can join a group several times; it must then leave the group the same number of times. leave(Name, Pid) -> ok | {error, Reason} Types Name = term() Pid = pid() Reason = {no_such_group, Name} Makes the process Pid leave the group Name . If the process is not a member of the group, ok is returned. which_groups() -> [Name] Types Name = term() Returns a list of all known groups. start() start_link() -> {ok, Pid} | {error, Reason} Types Pid = pid() Reason = term() 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(7) , pg(3erl) Ericsson AB kernel 2.14.3 pg2(3erl)

Check Out this Related Man Page

snmpa_network_interface(3erl)				     Erlang Module Definition				     snmpa_network_interface(3erl)

NAME
snmpa_network_interface - Behaviour module for the SNMP agent network interface. DESCRIPTION
This module defines the behaviour of the agent network interface. A snmpa_network_interface compliant module must export the following functions: * start_link/4 * info/1 * get_log_type/1 * set_log_type/2 * verbosity/2 The semantics of them and their exact signatures are explained below. But this is not enough. There is also a set of mandatory messages which the network interface entity must be able to receive and be able to send. This is described in chapter snmp_agent_netif . EXPORTS
start_link(Prio, NoteStore, MasterAgent, Opts) -> {ok, Pid} | {error, Reason} Types Prio = priority() NoteStore = pid() MasterAgent = pid() Opts = [opt()] opt() = {verbosity, verbosity()} | {versions, versions()} | term() versions() = [version()] version() = v1 | v2 | v3 Start-link the network interface process. NoteStore is the pid of the note-store process and MasterAgent is the pid of the master-agent process. Opts is an (basically) implementation dependent list of options to the network interface process. There are however a number of options which must be handled: versions and verbosity . info(Pid) -> [{Key, Value}] Types Pid = pid() The info returned is basically up to the implementer to decide. This implementation provided by the application provides info about memory allocation and various socket information. The info returned by this function is returned together with other info collected by the agent when the info function is called (tagged with with the key net_if ). verbosity(Pid, Verbosity) -> void() Types Pid = pid() Verbosity = verbosity() Change the verbosity of a running network interface process. get_log_type(Pid) -> {ok, LogType} | {error, Reason} Types Pid = pid() LogType = atl_type() Reason = term() The Audit Trail Log is managed by the network interface process. So, it is this process that has to retrieve the actual log-type. set_log_type(Pid, NewType) -> {ok, OldType} | {error, Reason} Types Pid = pid() NewType = OldType = atl_type() Reason = term() The Audit Trail Log is managed by the network interface process. So, it is this process that has to do the actual changing of the type. See set_log_type for more info. Ericsson AB snmp 4.19 snmpa_network_interface(3erl)
Man Page