Return-Path: Delivered-To: apmail-new-httpd-archive@apache.org Received: (qmail 78449 invoked by uid 500); 1 Jun 2000 23:57:15 -0000 Mailing-List: contact new-httpd-help@apache.org; run by ezmlm Precedence: bulk X-No-Archive: yes Reply-To: new-httpd@apache.org list-help: list-unsubscribe: list-post: Delivered-To: mailing list new-httpd@apache.org Received: (qmail 78375 invoked from network); 1 Jun 2000 23:57:14 -0000 Date: Thu, 1 Jun 2000 16:57:15 -0700 From: Manoj Kasichainula To: new-httpd@apache.org Subject: Re: cvs commit: apache-2.0/src CHANGES Message-ID: <20000601165714.C3613@manojk.users.mindspring.com> Mail-Followup-To: new-httpd@apache.org References: <001601bfcbfe$21662fe0$345985d0@corecomm.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.2i In-Reply-To: ; from rbb@covalent.net on Thu, Jun 01, 2000 at 01:30:12PM -0700 X-Spam-Rating: locus.apache.org 1.6.2 0/1000/N On Thu, Jun 01, 2000 at 01:30:12PM -0700, rbb@covalent.net wrote: > I still like the idea of MPM's that don't have (or need) shared memory > creating their own stub functions that just call the regular memory > allocation functions. +1. In fact, I'd go a step further, and say that MPM's should export functions to allocate server-wide memory. For multiprocess MPMs on OSes with shared memory, they would call ap_shm_*. For uniprocess MPMs, they call malloc/free. For multiprocess MPMs on OSes without shared memory (I haven't paid enough attention to know if there are any of these), don't implement the functions at all, and modules that need these functions will fail to build (as they should). As the good man said, a level of indirection will solve all your problems.