Author: Yurii Rashkovskii <yrashk(at)gmail(dot)com>
Status: Draft
Type: Standards Track
Erlang-Version: R15A
Created: 2-Jul-2011
Post-History: 2-Jul-2011

---

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

erlang:group_leader(io)

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()).
true
2>  erlang:group_leader().
<0.24.0>
3> erlang:group_leader(io).
<0.24.0>
4> erlang:group_leader(test).
<0.31.0>
5> spawn(fun() -> io:format("~p~n",[erlang:group_leader()]) end), ok.
<0.24.0>
ok
6> spawn(fun() -> io:format("~p~n",[erlang:group_leader(io)]) end), ok.
<0.24.0>
ok
7> spawn(fun() -> io:format("~p~n",[erlang:group_leader(test)]) end), ok.
<0.31.0>
ok
8> spawn(fun() -> io:format("~p~n",[erlang:process_info(self())]) end), ok.
[{current_function,{erl_eval,do_apply,5}},
 {initial_call,{erlang,apply,2}},
 {status,running},
 {message_queue_len,0},
 {messages,[]},
 {links,[]},
 {dictionary,[]},
 {trap_exit,false},
 {error_handler,error_handler},
 {priority,normal},
 {group_leader,<0.24.0>},
 {group_leaders,[{test,<0.31.0>},{io,<0.24.0>}]},
 {total_heap_size,233},
 {heap_size,233},
 {stack_size,24},
 {reductions,93},
 {garbage_collection,[{min_bin_vheap_size,46368},
                      {min_heap_size,233},
                      {fullsweep_after,65535},
                      {minor_gcs,0}]},
 {suspending,[]}]
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.