From 5ed99ed1435f6964348e96fc28dac4d0fb830dfc Mon Sep 17 00:00:00 2001 From: David Reid Date: Tue, 8 Jan 2002 16:37:52 +0000 Subject: [PATCH] Update the FreeBSD saga... git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@92770 13f79535-47bb-0310-9956-ffa450edef68 --- CHANGES | 5 +++++ STATUS | 15 +-------------- 2 files changed, 6 insertions(+), 14 deletions(-) diff --git a/CHANGES b/CHANGES index 48ab0df525..d1190b7184 100644 --- a/CHANGES +++ b/CHANGES @@ -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)] diff --git a/STATUS b/STATUS index 8abaa52fcb..f146c6de53 100644 --- a/STATUS +++ b/STATUS @@ -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 @@ RELEASE NON-SHOWSTOPPERS BUT WOULD BE REAL NICE TO WRAP THESE UP: (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, @@ -171,13 +165,6 @@ RELEASE NON-SHOWSTOPPERS BUT WOULD BE REAL NICE TO WRAP THESE UP: 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. Reasons include sole-function servers that need to die if -- 2.40.0