httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Stoddard" <b...@wstoddard.com>
Subject [PATCH] Eliminate HARD_THREAD_LIMIT on Windows
Date Sat, 22 Dec 2001 05:28:40 GMT
So I says to myself, "self, why introduce the ThreadLimit directive when the scoreboard on
Windows is not shared between processes, ever?". So here is a patch: the scoreboard is
always allocated to be exactly big enough for ThreadsPerChild entries. And it can grow or
shrink across restarts because the scoreboard is never shared across processes. Why didn't
I think o this sooner? It's late so posting a patch rather than committing code...

Bill

Index: mpm_winnt.c
===================================================================
RCS file: /home/cvs/httpd-2.0/server/mpm/winnt/mpm_winnt.c,v
retrieving revision 1.202
diff -u -r1.202 mpm_winnt.c
--- mpm_winnt.c 2001/12/18 13:48:53 1.202
+++ mpm_winnt.c 2001/12/22 05:21:53
@@ -75,27 +75,9 @@
 #include "mpm_common.h"
 #include <malloc.h>

-/* Limit on the threads per process.  Clients will be locked out if more than
- * this  * HARD_SERVER_LIMIT are needed.
- *
- * We keep this for one reason it keeps the size of the scoreboard file small
- * enough that we can read the whole thing without worrying too much about
- * the overhead.
- */
-#ifndef HARD_THREAD_LIMIT
-#define HARD_THREAD_LIMIT 4096
-#endif
-
-/* Limit on the total --- clients will be locked out if more servers than
- * this are needed.  It is intended solely to keep the server from crashing
- * when things get out of hand.
- *
- * We keep a hard maximum number of servers, for two reasons --- first off,
- * in case something goes seriously wrong, we want to stop the fork bomb
- * short of actually crashing the machine we're running on by filling some
- * kernel table.  Secondly, it keeps the size of the scoreboard file small
- * enough that we can read the whole thing without worrying too much about
- * the overhead.
+
+/*
+ * Maximum number of processes access the scoreboard at once
  */
 #define HARD_SERVER_LIMIT 1

@@ -1592,7 +1574,7 @@
             *result = HARD_SERVER_LIMIT;
             return APR_SUCCESS;
         case AP_MPMQ_HARD_LIMIT_THREADS:
-            *result = HARD_THREAD_LIMIT;
+            *result = ap_threads_per_child;
             return APR_SUCCESS;
         case AP_MPMQ_MAX_THREADS:
             *result = ap_threads_per_child;
@@ -2016,7 +1998,10 @@
         ap_log_error(APLOG_MARK, APLOG_INFO, APR_SUCCESS, ap_server_conf,
                      "Child %d: Child process is running", my_pid);

-        /* Set up the scoreboard. */
+        /* Set up the scoreboard. The size is based on the setting of
+         * ap_threads_per_child. Since the scoreboard is not shared
+         * between processes, it can be resized across restarts.
+         */
         ap_run_pre_mpm(pconf, SB_NOT_SHARED);
         /* Humm... Should we put the parent pid here? Does it matter
          * since the scoreboard is not shared?
@@ -2090,20 +2075,8 @@
     if (err != NULL) {
         return err;
     }
-
     ap_threads_per_child = atoi(arg);
-    if (ap_threads_per_child > HARD_THREAD_LIMIT) {
-        ap_log_error(APLOG_MARK, APLOG_STARTUP | APLOG_NOERRNO, 0, NULL,
-                     "WARNING: ThreadsPerChild of %d exceeds compile time"
-                     " limit of %d threads,", ap_threads_per_child,
-                     HARD_THREAD_LIMIT);
-        ap_log_error(APLOG_MARK, APLOG_STARTUP | APLOG_NOERRNO, 0, NULL,
-                     " lowering ThreadsPerChild to %d. To increase, please"
-                     " see the  HARD_THREAD_LIMIT define in %s.",
-                     HARD_THREAD_LIMIT, AP_MPM_HARD_LIMITS_FILE);
-        ap_threads_per_child = HARD_THREAD_LIMIT;
-    }
-    else if (ap_threads_per_child < 1) {
+    if (ap_threads_per_child < 1) {
  ap_log_error(APLOG_MARK, APLOG_STARTUP | APLOG_NOERRNO, 0, NULL,
                      "WARNING: Require ThreadsPerChild > 0, setting to 1");
  ap_threads_per_child = 1;



Mime
View raw message