httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Bannert <aa...@clove.org>
Subject Re: Apache 2.0.36 w/ FreeBSD ... 'hangs' ...
Date Tue, 21 May 2002 16:24:39 GMT
On Tue, May 21, 2002 at 01:14:00PM -0300, Marc G. Fournier wrote:
> Just to confirm, would it be the following that I'm looking at:
...

Nope, further down:

    * FreeBSD, threads, and worker MPM.  All seems to work fine 
      if you only have one worker process with many threads.  Add
      a second worker process and the accept lock seems to be
      lost.  This might be an APR issue with how it deals with
      the child_init hook (i.e. the fcntl lock needs to be resynced).
      More examination and analysis is required.
        Status: This has also been reported on Cygwin.  
        Message-ID: <3C2CC514.8EF3BED1@wapme-systems.de> (cygnus)

      Justin says: So, FreeBSD-CURRENT and Cywin have the same 
                   problem.  Yum.  If another platform has this
                   with worker, this becomes a showstopper.
      Aaron says: I spent some time disecting this and have come to
              the conclusion that it is not a problem in the worker MPM
              (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:
               - 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,
                 at first the child or children will appear to work
                 properly. At times it is possible to get it into a state,
                 however, where a request will hang until another concurrent
                 request "kicks" the first, at which point the second will
                 hang. My theory is that this has to do with the
                 pthread_cond_*() implementation in FreeBSD, but it's still
                 possible that it is in APR.

      Justin adds: Oh, FreeBSD threads are implemented entirely with
                   select()/poll()/longjmp().  Welcome to the nightmare.
                   So, that means a ktrace output also has the thread
                   scheduling internals in it (since it is all the same to
                   the kernel).  Which makes it hard to distinguish between
                   our select() calls and their select() calls.
                   *bangs head on wall repeatedly*  But, some of the libc_r
                   files have a DBG_MSG #define.  This is moderately helpful
                   when used with -DNO_DETACH.  The kernel scheduler isn't
                   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.

-aaron

Mime
View raw message