jerenkrantz 01/09/08 02:07:36
Modified: . STATUS
Log:
- 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 @@
APACHE PORTABLE RUNTIME (APR) LIBRARY STATUS:
-*-text-*-
-Last modified at [$Date: 2001/08/24 18:04:24 $]
+Last modified at [$Date: 2001/09/08 09:07:36 $]
Release:
@@ -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: <[EMAIL PROTECTED]>
+
Documentation that needs writing:
* API documentation
