add sys:get_state/1,2 and sys:replace_state/2,3

At Erlang Factory 2013 there was discussion during one of the talks about
the sys:get_status functions and how useful they were for debugging. Geoff
Cant mentioned it would be very useful if the sys module also provided
functions to use while debugging to get just the state of a process and
also to be able to replace the state of a process, and many others in the
audience appeared to agree.

The sys:get_state/1,2 functions return the state of a gen_server, gen_fsm,
or gen_event process. The return value varies depending on the process
type: process state for a gen_server, state name and state data for a
gen_fsm, and handler module, handler id, and handler state for each handler
registered in a gen_event process.

The sys:replace_state/2,3 functions allow the state of a gen_server,
gen_fsm, or gen_event process to be replaced with a new state. These
functions take a function argument that updates or replaces the process
state; using a function to change the state eliminates the race condition
of first reading the state via sys:get_state/1 or sys:get_state/2, using
its return value to create a new state, and then replacing the old state
with the new state, since during that time the process might have received
other calls or messages that could have changed its state.

* For a gen_server process, the state replacement function takes the
  process state as an argument and returns a new state.

* For a gen_fsm process, the state replacement function gets a tuple of
  {StateName, StateData} and returns a similar tuple that specifies a new
  state name, new state data, or both.

* For a gen_event process, the state replacement function is called for
  each registered event handler. It gets a tuple {Module, Id, HandlerState}
  and returns a similar tuple that specifies the same Module and Id values
  but may specify a different value for HandlerState.

If the state replacement function crashes or results in an error, the
original state of a gen_server or gen_fsm process is maintained; if such a
crash occurs for a gen_event process, the original state of the event
handler for which the state replacement function was called is maintained,
but the states of other event handlers of the same gen_event process may
still be updated if no errors or crashes occur while replacing their
states.

Add documentation for sys:get_state/1,2 and sys:replace_state/2,3. The
documentation explicitly notes that the functions are intended for use
during debugging.

Add new tests for these functions to gen_server_SUITE, gen_fsm_SUITE, and
gen_event_SUITE.

1 files changed, 67 insertions, 0 deletions

diff --git a/lib/stdlib/doc/src/sys.xml b/lib/stdlib/doc/src/sys.xml
index bb75efb5e7..a177b80739 100644
--- a/lib/stdlib/doc/src/sys.xml
+++ b/lib/stdlib/doc/src/sys.xml
@@ -225,6 +225,73 @@
       </desc>
     </func>
     <func>
+      <name name="get_state" arity="1"/>
+      <name name="get_state" arity="2"/>
+      <fsummary>Get the state of the process</fsummary>
+      <desc>
+        <p>Gets the state of the process.</p>
+        <note>
+          <p>These functions are intended only to help with debugging. They are provided for
+            convenience, allowing developers to avoid having to create their own state extraction
+            functions and also avoid having to interactively extract state from the return values of
+            <c><seealso marker="get_status/1">get_status/1</seealso></c> or
+            <c><seealso marker="get_status/2">get_status/2</seealso></c> while debugging.</p>
+        </note>
+        <p>The value of <c><anno>State</anno></c> varies for different types of
+          processes. For a <c>gen_server</c> process, the returned <c><anno>State</anno></c>
+          is simply the callback module's state. For a <c>gen_fsm</c> process,
+          <c><anno>State</anno></c> is the tuple <c>{CurrentStateName, CurrentStateData}</c>.
+          For a <c>gen_event</c> process, <c><anno>State</anno></c> a list of tuples,
+          where each tuple corresponds to an event handler registered in the process and contains
+          <c>{Module, Id, HandlerState}</c>, where <c>Module</c> is the event handler's module name,
+          <c>Id</c> is the handler's ID (which is the value <c>false</c> if it was registered without
+          an ID), and <c>HandlerState</c> is the handler's state.</p>
+        <p>To obtain more information about a process, including its state, see
+          <seealso marker="get_status/1">get_status/1</seealso> and
+          <seealso marker="get_status/2">get_status/2</seealso>.</p>
+      </desc>
+    </func>
+    <func>
+      <name name="replace_state" arity="2"/>
+      <name name="replace_state" arity="3"/>
+      <fsummary>Replace the state of the process</fsummary>
+      <desc>
+        <p>Replaces the state of the process, and returns the new state.</p>
+        <note>
+          <p>These functions are intended only to help with debugging, and they should not be
+            be called from normal code. They are provided for convenience, allowing developers
+            to avoid having to create their own custom state replacement functions.</p>
+        </note>
+        <p>The <c><anno>StateFun</anno></c> function provides a new state for the process.
+          The <c><anno>State</anno></c> argument and <c><anno>NewState</anno></c> return value
+          of <c><anno>StateFun</anno></c> vary for different types of processes. For a
+          <c>gen_server</c> process, <c><anno>State</anno></c> is simply the callback module's
+          state, and <c><anno>NewState</anno></c> is a new instance of that state. For a
+          <c>gen_fsm</c> process, <c><anno>State</anno></c> is the tuple
+          <c>{CurrentStateName, CurrentStateData}</c>, and <c><anno>NewState</anno></c>
+          is a similar tuple that may contain a new state name, new state data, or both.
+          For a <c>gen_event</c> process, <c><anno>State</anno></c> is the tuple
+          <c>{Module, Id, HandlerState}</c> where <c>Module</c> is the event handler's module name,
+          <c>Id</c> is the handler's ID (which is the value <c>false</c> if it was registered without
+          an ID), and <c>HandlerState</c> is the handler's state. <c><anno>NewState</anno></c> is a
+          similar tuple where <c>Module</c> and <c>Id</c> shall have the same values as in
+          <c><anno>State</anno></c> but the value of <c>HandlerState</c> may be different. Returning
+          a <c><anno>NewState</anno></c> whose <c>Module</c> or <c>Id</c> values differ from those of
+          <c><anno>State</anno></c> will result in the event handler's state remaining unchanged. For a
+          <c>gen_event</c> process, <c><anno>StateFun</anno></c> is called once for each event handler
+          registered in the <c>gen_event</c> process.</p>
+        <p>If a <c><anno>StateFun</anno></c> function decides not to effect any change in process
+          state, then regardless of process type, it may simply return its <c><anno>State</anno></c>
+          argument.</p>
+        <p>If a <c><anno>StateFun</anno></c> function crashes or throws an exception, then
+          for <c>gen_server</c> and <c>gen_fsm</c> processes, the original state of the process is
+          unchanged. For <c>gen_event</c> processes, a crashing or failing <c><anno>StateFun</anno></c>
+          function means that only the state of the particular event handler it was working on when it
+          failed or crashed is unchanged; it can still succeed in changing the states of other event
+          handlers registered in the same <c>gen_event</c> process.</p>
+      </desc>
+    </func>
+    <func>
       <name name="install" arity="2"/>
       <name name="install" arity="3"/>
       <fsummary>Install a debug function in the process</fsummary>