You are viewing a plain text version of this content. The canonical link for it is here.
Posted to cvs@httpd.apache.org by ma...@hyperreal.org on 1999/05/24 05:47:40 UTC
cvs commit: apache-apr STATUS
manoj 99/05/23 20:47:39
Modified: . STATUS
Log:
I saw Rob Malda take apart the circuitry in his beer mug last night.
Revision Changes Path
1.24 +1 -19 apache-apr/STATUS
Index: STATUS
===================================================================
RCS file: /home/cvs/apache-apr/STATUS,v
retrieving revision 1.23
retrieving revision 1.24
diff -u -u -r1.23 -r1.24
--- STATUS 1999/04/29 19:34:19 1.23
+++ STATUS 1999/05/24 03:47:39 1.24
@@ -1,5 +1,5 @@
Apache Portable Runtime STATUS:
-Last modified at [$Date: 1999/04/29 19:34:19 $]
+Last modified at [$Date: 1999/05/24 03:47:39 $]
Release:
@@ -42,24 +42,6 @@
Everything
Needs patch:
-
- When the server runs at a high load, and the load later drops off,
- the server tries to kill off some children. The problem is that the
- children selected may have threads blocked on the accept lock, so
- they will never exit. This wasn't a problem with 1.3, because each
- process got kicked out of the lock with a signal. This could be solved
- (Thanks, Dean) with a server-wide pipe that replaces the SIGWINCH signal.
- This would wake up every thread when a single child death signal is sent
- over the pipe.
-
- Related to the above: On Red Hat 5.2, when we SIGTERM the server and
- the server is in this state, the children waiting on fcntl will not
- die, even though nobody else is holding the lock, verified with lsof.
- The children eventually will be SIGKILLed by the parent. This only
- happens in USE_MULTI_ACCEPT mode, and the problem goes away when
- USE_INTRAPROCESS_SERIALIZED_ACCEPT is undefined. Dean has a couple of
- suggestions for tracing down this problem in
- <Pi...@twinlark.arctic.org>
Open issues: