apr-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From jerenkra...@apache.org
Subject cvs commit: apr STATUS
Date Sat, 08 Sep 2001 09:07:36 GMT
jerenkrantz    01/09/08 02:07:36

  Modified:    .        STATUS
  - Add note about fcntl() breakage seen on Solaris 8.  This is just odd.
    Switching to pthread_mutex_t works just fine (that requires a patch to
    configure.in though)...  =-)
  - While we don't think that the FreeBSD threads/sendfile thing is our
    problem (ktrace seems to confirm that we are doing the "right" thing),
    we *should* send a bug report to the FreeBSD people so that one of their
    people can take a look at it.  Do we know any FreeBSD people?
  Revision  Changes    Path
  1.61      +31 -1     apr/STATUS
  Index: STATUS
  RCS file: /home/cvs/apr/STATUS,v
  retrieving revision 1.60
  retrieving revision 1.61
  diff -u -r1.60 -r1.61
  --- STATUS	2001/08/24 18:04:24	1.60
  +++ STATUS	2001/09/08 09:07:36	1.61
  @@ -1,5 +1,5 @@
  -Last modified at [$Date: 2001/08/24 18:04:24 $]
  +Last modified at [$Date: 2001/09/08 09:07:36 $]
  @@ -185,6 +185,36 @@
       * apr_xlate.h generates a bunch of compiler warnings.
  +    * fcntl() oddness on Solaris.  Under high loads, fcntl() decides to
  +      return error code 46 (ENOLCK).
  +      httpd (prefork MPM) error log says (predictably):
  +      (46)No record locks available: couldn't grab the accept mutex
  +      All of the children report this and subsequently exits.  httpd is now 
  +      hosed.  AFAICT, this does not look to be an out-of-fds error.
  +      Solaris's man page says:
  +        ENOLCK
  +           The  cmd argument is F_SETLK, F_SETLK64, F_SETLKW,  or
  +           F_SETLKW64  and  satisfying the lock or unlock request
  +           would result in the number of locked  regions  in  the
  +           system exceeding a system-imposed limit.
  +      Justin says: What is this system-imposed limit and how do we change it?
  +                   This gives me more rationale for switching the default
  +                   interprocess lock mechanism to pthread (if available).
  +    * Generate a good bug report to send to the FreeBSD hackers that details
  +      the problems we have seen with threads and system calls (specifically
  +      sendfile data is corrupted).  From our analysis so far, we don't think 
  +      that this is an APR issue, but rather a FreeBSD kernel issue.  Our
  +      current solution is to just disable threads across the board on
  +      FreeBSD.
  +      MsgID: <20010828091959.D17570@ebuilt.com>
   Documentation that needs writing:
       * API documentation

View raw message