Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP
Browse files

Edited eeps/eep-scoped-group-leaders.md via GitHub

  • Loading branch information...
commit 7dea3555e7f5bcba169b8708694ce1385518fe65 1 parent c963530
@rampage authored
Showing with 42 additions and 44 deletions.
  1. +42 −44 eeps/eep-scoped-group-leaders.md
View
86 eeps/eep-scoped-group-leaders.md
@@ -13,58 +13,57 @@ EEP XXX: Scoped Group Leaders
Abstract
========
-Scoped group leaders is an extension of an existing group leader
-mechanism that allows to use group leaders beyond their
-original intent (I/O only).
+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 gets a "dictionary" of group leaders, with one group
-leader `io` defined by default that represents the only one group
-leader that exists in current implementation of Erlang. On every
-new process creation the entire dictionary is copied over just
-like a single group leader was copied before.
+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 were added to the `erlang` module.
+Two new functions have been added to the `erlang` module.
-First one, scoped group leader retrieval:
+Firstly, scoped group leader retrieval:
erlang:group_leader(Scope :: atom()) -> 'undefined' | pid()
-This function retrieves group leader for scope `Scope`. Existing
-argumentless function `erlang:group_leader/0` is now implemented as
+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)
-Second one, scoped group leader setup:
+Secondly, scoped group leader setup:
erlang:group_leader(Scope :: atom(), GroupLeader :: pid(),
Proc :: pid()) -> true.
-This function sets group leader for scope `Scope` to `GroupLeader`
-for a process `Proc`. Existing function `erlang:group_leader/2` is
+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 will contain a proplist of group leaders associated with the process.
-Note that it will always contain at least one tuple like `{io, <0.24.0>}`
-as this group leader is present in every single process.
+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 gets extended to support these scoped group leaders
-as well, so processed spawned on remote nodes get the whole list of group
+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 will retrieve it from the current and child processes. We'll
-also retrieve `io` scoped group leader using both original and new
-API:
+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
@@ -111,40 +110,39 @@ API:
Motivation
==========
-I/O system is not the only domain where a concept of group leaders
-comes handy. Implicit configurations, security groups and many other
-problems would benefit from being able to use this generalized group
-leader mechanism.
+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
-I/O leader paradigm into web development, with a `web` group leader
-representing an HTTP connection, WebSocket or a session. With this
+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 access to HTTP communication channels, within either local
-or remote processes.
+transparent and/or multiplexed access to other HTTP communication channels,
+within either local or remote processes.
Rationale
=========
-We have chosen to extend existing API instead of introducing a new one
-simply because this concept is a natural evolution of group leaders with
-which people are already familiar.
+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
=======================
-This proposed change keeps existing API intact and only provides new
-functions for this new described functionality, therefore making this change
-backwards compatible. Existing behaviours are not altered and newly
-introduced behaviours are built to mimick existing ones.
-
-Proplist returned by `erlang:process_info/1` has all pre-existing keys
-unmodified and features a new key called `group_leaders`. Unless some code
-relied on a specific set of keys used in this proplist, no backwards compatibility
-issues should exist in this regard.
+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
========================
Please sign in to comment.
Something went wrong with that request. Please try again.