mpm-event's doc rebuild

git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1772400 13f79535-47bb-0310-9956-ffa450edef68

diff --git a/docs/manual/mod/event.html.en b/docs/manual/mod/event.html.en
index 7f61dd4b0de7c0aef8ea54b3a4c669c0b1dae173..ed35c9742717c80e8875f0d4408a5e0d0691ca6c 100644 (file)
--- a/docs/manual/mod/event.html.en
+++ b/docs/manual/mod/event.html.en
@@ -150,7 +150,7 @@ of the <code class="directive">AsyncRequestWorkerFactor</code>.</p>
         and also the number of allowed processes
         (<code class="directive"><a href="../mod/mpm_common.html#maxrequestworkers">MaxRequestWorkers</a></code> 
         / <code class="directive"><a href="../mod/mpm_common.html#threadsperchild">ThreadsPerChild</a></code>), meanwhile
-        the Scoreboad is a representation of all the running processes and
+        the Scoreboard is a representation of all the running processes and
         the status of their worker threads. If the scoreboard is full (so all the
         threads have a state that is not idle) but the number of active requests
         served is not <code class="directive"><a href="../mod/mpm_common.html#maxrequestworkers">MaxRequestWorkers</a></code>,
@@ -158,17 +158,24 @@ of the <code class="directive">AsyncRequestWorkerFactor</code>.</p>
         but that are queued instead (up to the limit imposed by
         <code class="directive"><a href="../mod/mpm_common.html#listenbacklog">ListenBacklog</a></code>). Most of the times
         the threads are stuck in the Graceful state, namely they are waiting to
-        finish their work with a TCP connection to terminate and free a
+        finish their work with a TCP connection to safely terminate and free up a
         scoreboard slot (for example handling long running requests, slow clients
-        or a connection with keep-alive enabled). Two scenarios are very common:</p>
+        or connections with keep-alive enabled). Two scenarios are very common:</p>
         <ul>
-            <li>Httpd graceful restart.</li>
+            <li>During a <a href="../stopping.html#graceful">graceful restart</a>.
+            The parent process signals all its children to complete
+            their work and terminate, while it reloads the config and forks new
+            processes. If the old children keep running for a while before stopping,
+            the scoreboard will be partially occupied until their slots are freed.
+            </li>
             <li>When the server load goes down in a way that causes httpd to
             stop some processes (for example due to
             <code class="directive"><a href="../mod/mpm_common.html#maxsparethreads">MaxSpareThreads</a></code>).
             This is particularly problematic because when the load increases again,
-            httpd will try to start more processes.
-            If the pattern repeats, the number of processes can rise quite a bit.
+            httpd will try to start new processes.
+            If the pattern repeats, the number of processes can rise quite a bit,
+            ending up in a mixture of old processes trying to stop and new ones
+            trying to do some work.
             </li>
         </ul>
         <p>From 2.4.24 onward, mpm-event is smarter and it is able to handle