[eeps] EEP for scoped group leaders

Yurii Rashkovskii <>
Wed Aug 3 18:47:41 CEST 2011


I would like to submit an EEP for scoped group leaders, a backward
compatible extension for group leader functionality. You can find its
up-to-date version at
or attached to this message.

It has received some positive feedback on the mailing list
and it was discussed with the other community members on IRC fairly
exhaustively and was positively reviewed there as well.

Please let me know if there's anything else needed to get this EEP processed.

-------------- next part --------------
    Author: Yurii Rashkovskii <>
    Status: Draft
    Type: Standards Track
    Erlang-Version: R15A
    Created: 2-Jul-2011
    Post-History: 2-Jul-2011
EEP XXX: Scoped Group Leaders


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).


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.


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.


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

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.


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][1].

[1]: https://github.com/spawngrid/otp/tree/group_leader_scope


This document has been placed in the public domain.

[EmacsVar]: <> "Local Variables:"
[EmacsVar]: <> "mode: indented-text"
[EmacsVar]: <> "indent-tabs-mode: nil"
[EmacsVar]: <> "sentence-end-double-space: t"
[EmacsVar]: <> "fill-column: 70"
[EmacsVar]: <> "coding: utf-8"
[EmacsVar]: <> "End:"

More information about the eeps mailing list