REFORKING.md in pitchfork-0.3.0

- old
+ new

@@ -44,54 +44,64 @@
 That is where reforking helps. Since move of these invalidations only happens when a codepath is executed for the
 first time, if you take a warmed up worker out of rotation, and use it to fork new workers, warmed up pages will
 be shared again, and most of them won't be invalidated anymore.
 
 
-When you start `pitchfork` it forks the desired amount of workers:
+When you start `pitchfork` it forks a `mold` process which loads your application:
 
 ```
 PID   COMMAND
 100   \_ pitchfork master
-101       \_ pitchfork worker[0] (gen:0)
-102       \_ pitchfork worker[1] (gen:0)
-103       \_ pitchfork worker[2] (gen:0)
-104       \_ pitchfork worker[3] (gen:0)
+101       \_ pitchfork (gen:0) mold
 ```
 
-When a reforking is triggered, one of the workers is selected to become a `mold`, and is taken out of rotation.
-When promoted, molds no longer process any incoming HTTP requests, they become inactive:
+Once the `mold` is done loading, the `master` asks it to spawn the desired number of workers:
 
 ```
 PID   COMMAND
 100   \_ pitchfork master
-101       \_ pitchfork mold (gen:1)
-102       \_ pitchfork worker[1] (gen:0)
-103       \_ pitchfork worker[2] (gen:0)
-104       \_ pitchfork worker[3] (gen:0)
+101       \_ pitchfork (gen:0) mold
+102       \_ pitchfork (gen:0) worker[0]
+103       \_ pitchfork (gen:0) worker[1]
+104       \_ pitchfork (gen:0) worker[2]
+105       \_ pitchfork (gen:0) worker[3]
 ```
 
-When a new mold has been promoted, `pitchfork` starts a slow rollout of older workers and replace them with fresh workers
+When a reforking is triggered, one of the workers is selected to fork a new `mold`.
+
+```
+PID   COMMAND
+100   \_ pitchfork master
+101       \_ pitchfork (gen:0) mold
+102       \_ pitchfork (gen:0) worker[0]
+103       \_ pitchfork (gen:0) worker[1]
+104       \_ pitchfork (gen:0) worker[2]
+105       \_ pitchfork (gen:0) worker[3]
+105       \_ pitchfork (gen:1) mold
+```
+
+When that new mold is ready, `pitchfork` terminates the old mold and starts a slow rollout of older workers and replace them with fresh workers
 forked from the mold:
 
 ```
 PID   COMMAND
 100   \_ pitchfork master
-101       \_ pitchfork mold (gen:1)
-105       \_ pitchfork worker[0] (gen:1)
-102       \_ pitchfork worker[1] (gen:0)
-103       \_ pitchfork worker[2] (gen:0)
-104       \_ pitchfork worker[3] (gen:0)
+102       \_ pitchfork (gen:0) worker[0]
+103       \_ pitchfork (gen:0) worker[1]
+104       \_ pitchfork (gen:0) worker[2]
+105       \_ pitchfork (gen:0) worker[3]
+105       \_ pitchfork (gen:1) mold
 ```
 
 ```
 PID   COMMAND
 100   \_ pitchfork master
-101       \_ pitchfork mold (gen:1)
-105       \_ pitchfork worker[0] (gen:1)
-106       \_ pitchfork worker[1] (gen:1)
-103       \_ pitchfork worker[2] (gen:0)
-104       \_ pitchfork worker[3] (gen:0)
+103       \_ pitchfork (gen:0) worker[1]
+104       \_ pitchfork (gen:0) worker[2]
+105       \_ pitchfork (gen:0) worker[3]
+105       \_ pitchfork (gen:1) mold
+106       \_ pitchfork (gen:1) worker[0]
 ```
 
 etc.
 
 ### Forking Sibling Processes 
@@ -101,10 +111,10 @@
 
 ```
 PID   COMMAND
 100   \_ pitchfork master
 101       \_ pitchfork mold (gen:1)
-105          \_ pitchfork worker[0] (gen:1)
+105          \_ pitchfork (gen:1) worker[0]
 ```
 
 However the `pitchfork` master process registers itself as a "child subreaper" via [`PR_SET_CHILD_SUBREAPER`](https://man7.org/linux/man-pages/man2/prctl.2.html).
 This means any descendant process that is orphaned will be re-parented as a child of the master rather than a child of the init process (pid 1).
 