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
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.
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
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.
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.
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.
There is no reference implementation at this point. However, a proof of concept implementation is available.
This document has been placed in the public domain.