]> granicus.if.org Git - apache/commitdiff
Update the FreeBSD saga...
authorDavid Reid <dreid@apache.org>
Tue, 8 Jan 2002 16:37:52 +0000 (16:37 +0000)
committerDavid Reid <dreid@apache.org>
Tue, 8 Jan 2002 16:37:52 +0000 (16:37 +0000)
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@92770 13f79535-47bb-0310-9956-ffa450edef68

CHANGES
STATUS

diff --git a/CHANGES b/CHANGES
index 48ab0df525e31c73b7431e959df516140b6f3565..d1190b718410a67bb09598fad14b80ef156ba596 100644 (file)
--- a/CHANGES
+++ b/CHANGES
@@ -1,5 +1,10 @@
 Changes with Apache 2.0.30-dev
 
+  *) Fix the main bug for FreeBSD and threaded MPM's. There are
+     still issues (see STATUS) but at least the server will now
+     run without crashing the machine.
+     [David Reid, Aaron Bannert, Justin Erenkrantz]
+
   *) Fix a typo in mod_deflate's m4 config section.
      [albert chin (china@thewrittenword.com)]
 
diff --git a/STATUS b/STATUS
index 8abaa52fcb56f1d8bb08dff435f3eb950085e493..f146c6de53531eee3d7f8317741a954134382503 100644 (file)
--- a/STATUS
+++ b/STATUS
@@ -1,5 +1,5 @@
 APACHE 2.0 STATUS:                                             -*-text-*-
-Last modified at [$Date: 2002/01/08 00:31:19 $]
+Last modified at [$Date: 2002/01/08 16:37:52 $]
 
 Release:
 
@@ -141,12 +141,6 @@ RELEASE NON-SHOWSTOPPERS BUT WOULD BE REAL NICE TO WRAP THESE UP:
               (or at least, it is not isolated to a problem in worker).
               I'll list some of the problems I'm seeing in case someone
               else wants to pick up where I've left off:
-               - The parent process goes into a loop consuming lots of CPU.
-                 It has to do with how waitpid() and apr_sleep() are called
-                 from within server_main_loop(). ktrace/kdump output shows
-                 some weird stuff happening with poll() and suspiciously
-                 small timeout values (apr_sleep() is implemented with
-                 select() which is implemented with poll()).
                - Delivery of just about any signal to one of the child
                  processes will send it into an infinite loop as well.
                - Even though the parent is spinning out of control,
@@ -171,13 +165,6 @@ RELEASE NON-SHOWSTOPPERS BUT WOULD BE REAL NICE TO WRAP THESE UP:
                    those decrementing select calls have to do with the 
                    scheduler.  Time to brush up on our OS fundamentals.
 
-      David says:  Having spent a fair bit of time tracking this further, it
-                   seems that FreeBSD's thread_kern_poll gets into a situation
-                   where it polls for the kern_pipe and gets a hit (so the
-                   timeout becomes an irrelevancy) but the pipe never seems to
-                   be read and so successive calls simply return and the cpu
-                   usage grows. Time to flag this to the FreeBSD team.
-
     * There is increasing demand from module writers for an API
       that will allow them to control the server à la apachectl.
       Reasons include sole-function servers that need to die if