Fixed wording about the event's doc page after Mike's feedback on dev@

git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/branches/2.4.x@1742031 13f79535-47bb-0310-9956-ffa450edef68

diff --git a/docs/manual/mod/event.xml b/docs/manual/mod/event.xml
index a5fa344ece7bbc431851c85721725c6d6ff1ae29..5a9162333a881ed06fb2c01b28b86bae56301f5e 100644 (file)
--- a/docs/manual/mod/event.xml
+++ b/docs/manual/mod/event.xml
@@ -61,15 +61,15 @@ of the <directive>AsyncRequestWorkerFactor</directive>.</p>
     significant overhead in creating TCP connections. However,
     Apache HTTP Server traditionally keeps an entire child
     process/thread waiting for data from the client, which brings its own disadvantages.
-    To solve this problem, this MPM uses a dedicated listener thread for each process 
-    to handle both the Listening sockets, all sockets that are in a Keep Alive state, 
+    To solve this problem, this MPM uses a dedicated listener thread for each process
+    to handle both the Listening sockets, all sockets that are in a Keep Alive state,
     sockets where the handler and protocol filters have done their work
     and the ones where the only remaining thing to do is send the data to the client.
     </p>
 
-    <p>This new architecture, leveraging non blocking sockets and modern kernel
+    <p>This new architecture, leveraging non-blocking sockets and modern kernel
        features exposed by <glossary>APR</glossary> (like Linux's epoll),
-       does not require anymore the <code>mpm_accept</code> <directive module="core">Mutex</directive>
+       no longer requires the <code>mpm-accept</code> <directive module="core">Mutex</directive>
        configured to avoid the thundering herd problem.</p>
 
     <p>The total amount of connections that a single process/threads block can handle is regulated