You are viewing a plain text version of this content. The canonical link for it is here.
Posted to cvs@httpd.apache.org by dr...@apache.org on 2002/01/08 17:37:53 UTC

cvs commit: httpd-2.0 STATUS CHANGES

dreid       02/01/08 08:37:53

  Modified:    .        STATUS CHANGES
  Log:
  Update the FreeBSD saga...
  
  Revision  Changes    Path
  1.376     +1 -14     httpd-2.0/STATUS
  
  Index: STATUS
  ===================================================================
  RCS file: /home/cvs/httpd-2.0/STATUS,v
  retrieving revision 1.375
  retrieving revision 1.376
  diff -u -r1.375 -r1.376
  --- STATUS	8 Jan 2002 00:31:19 -0000	1.375
  +++ STATUS	8 Jan 2002 16:37:52 -0000	1.376
  @@ -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 @@
                 (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,
  @@ -170,13 +164,6 @@
                      waking up the threads on a select().  Yum.  And, I bet 
                      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.
  
  
  
  1.504     +5 -0      httpd-2.0/CHANGES
  
  Index: CHANGES
  ===================================================================
  RCS file: /home/cvs/httpd-2.0/CHANGES,v
  retrieving revision 1.503
  retrieving revision 1.504
  diff -u -r1.503 -r1.504
  --- CHANGES	6 Jan 2002 00:44:22 -0000	1.503
  +++ CHANGES	8 Jan 2002 16:37:52 -0000	1.504
  @@ -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)]