Return-Path: Delivered-To: apmail-httpd-dev-archive@httpd.apache.org Received: (qmail 75429 invoked by uid 500); 18 Dec 2001 16:15:30 -0000 Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm Precedence: bulk Reply-To: dev@httpd.apache.org list-help: list-unsubscribe: list-post: Delivered-To: mailing list dev@httpd.apache.org Received: (qmail 75418 invoked from network); 18 Dec 2001 16:15:30 -0000 X-Authentication-Warning: rdu163-40-092.nc.rr.com: trawick set sender to trawick@attglobal.net using -f Sender: trawick@rdu163-40-092.nc.rr.com To: dev@httpd.apache.org Subject: Re: cvs commit: httpd-2.0/server/mpm/worker mpm_default.h worker.c References: <20011218134854.30281.qmail@icarus.apache.org> <3C1F67F8.C5784246@remulak.net> From: Jeff Trawick Date: 18 Dec 2001 11:14:31 -0500 In-Reply-To: <3C1F67F8.C5784246@remulak.net> Message-ID: Lines: 35 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Greg Ames writes: > > Hmmm... (2nd thoughts :) ) > > > > mpm_default.h exists so people can edit default settings in one nice > > place... it wasn't nice for me to move these things out of > > mpm_defaults.h... I'll move them back in there... hopefully these > > settings won't be abused by modules and instead modules will call > > ap_mpm_query() > > I wouldn't move them back. If you keep them out of the header file, > modules will have to use to use the MPM query functions, which is > goodness. Once we decide how to configure the limits for worker and > perchild, we can just use a subset of that stuff to set limits for the > other MPMs. > > Prefork doesn't have the same potential memory consumption problem as > worker, but it's still a pain to have to patch HARD_SERVER_LIMIT every > time we put a new build on daedalus. I would think the same applies to > Win32 and OS/2 with the current hard thread limits. patch for daedalus^H^H^H^H^H^H^H^Hprefork on its way... > Of course we don't want admins editing .c files as a rule. That would > be a step backwards. But if our goal is to put these params in the > config file, we can live with the limits in the MPM .c files for a day > or two. okay, let's defer any possible movement at least until we see what MPMs folks want to make smarter... -- Jeff Trawick | trawick@attglobal.net | PGP public key at web site: http://www.geocities.com/SiliconValley/Park/9289/ Born in Roswell... married an alien...