Yurii Rashkovskii <yrashk(at)gmail(dot)com>
Standards Track

EEP 39: Scoped Group Leaders #

Abstract #

Scoped group leaders is an extension of the existing group leader mechanism that allows one to use the group leader mechanism beyond its original intent (which is I/O only).

Specification #

Every process is given a “dictionary” of group leaders, with one io group leader defined by default, representing the only group leader that exists currently in Erlang. Every process created is given a copy of the dictionary exactly as before.

Two new functions have been added to the erlang module.

Firstly, scoped group leader retrieval:

erlang:group_leader(Scope :: atom()) -> 'undefined' | pid()

This function retrieves the group leader for the scope Scope. Existing argument-free function erlang:group_leader/0 is now implemented as


Secondly, scoped group leader setup:

erlang:group_leader(Scope :: atom(), GroupLeader :: pid(),
                                     Proc :: pid()) -> true.

This function sets the group leader for scope the Scope to the GroupLeader for a process Proc. The existing function erlang:group_leader/2 is now implemented as

erlang:group_leader(io, GroupLeader, Proc)

Process information available through erlang:process_info/1 and erlang:process_info/2 has been extended with a new key, group_leaders. It contains a proplist of group leaders associated with the process given. The list will at the very least contain the tuple {io, <0.24.0>} Note: this group leader is currently the default one in every single process.

Distribution mechanism(s) get extended to support these scoped group leaders as well, so processes spawned on remote nodes get the whole list of group leaders copied.

Example #

In this example, we’ll set a group leader for the scope of test and we’ll retrieve it from the current and the child processes. Also, we’ll retrieve the io scoped group leader using both the original and the new API:

1> erlang:group_leader(test, self(), self()).
2>  erlang:group_leader().
3> erlang:group_leader(io).
4> erlang:group_leader(test).
5> spawn(fun() -> io:format("~p~n",[erlang:group_leader()]) end), ok.
6> spawn(fun() -> io:format("~p~n",[erlang:group_leader(io)]) end), ok.
7> spawn(fun() -> io:format("~p~n",[erlang:group_leader(test)]) end), ok.
8> spawn(fun() -> io:format("~p~n",[erlang:process_info(self())]) end), ok.

Motivation #

The I/O system is not the only domain where the concept of group leaders comes in handy. Implicit configurations, security groups and many other problems could benefit from being able to extend the standard group leader mechanism.

One of the potential uses of this technique could be an extension of the I/O leader paradigm into Web Development, with a web group leader represented as an HTTP connection, WebSocket, or Session. With this simple approach one can use the same technique used by I/O primitives to allow transparent and/or multiplexed access to other HTTP communication channels, within either local or remote processes.

Rationale #

We have chosen to extend the existing API instead of introducing a new one simply because we believe this concept to be a natural evolution of the group leaders concept with which people are already familiar.

Backwards Compatibility #

The proposed changes keep existing API’s intact and only provide some new functions for this pre-described functionality. While this change maintains backwards compatibility, the existing behaviour’s are not altered and newly introduced behaviour’s are fashioned to mimic existing ones.

The Proplist returned by erlang:process_info/1 has all pre-existing keys unmodified and features, with the addition of a new key called group_leaders. In the unlikely event that code exists which relies on a specific set of keys used in this proplist, no backwards compatibility issues should exist.

Reference Implementation #

There is no reference implementation at this point. However, a proof of concept implementation is available.

Copyright #

This document has been placed in the public domain.