Return-Path: Delivered-To: apmail-apr-dev-archive@www.apache.org Received: (qmail 64994 invoked from network); 8 Sep 2006 08:14:41 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 8 Sep 2006 08:14:41 -0000 Received: (qmail 97845 invoked by uid 500); 8 Sep 2006 08:14:39 -0000 Delivered-To: apmail-apr-dev-archive@apr.apache.org Received: (qmail 97794 invoked by uid 500); 8 Sep 2006 08:14:39 -0000 Mailing-List: contact dev-help@apr.apache.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Id: Delivered-To: mailing list dev@apr.apache.org Received: (qmail 97783 invoked by uid 99); 8 Sep 2006 08:14:39 -0000 Received: from idunn.apache.osuosl.org (HELO idunn.apache.osuosl.org) (140.211.166.84) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 08 Sep 2006 01:14:39 -0700 Authentication-Results: idunn.apache.osuosl.org smtp.mail=jorton@redhat.com; spf=pass X-ASF-Spam-Status: No, hits=0.0 required=5.0 tests= Received-SPF: pass (idunn.apache.osuosl.org: domain redhat.com designates 66.187.233.31 as permitted sender) Received: from ([66.187.233.31:60270] helo=mx1.redhat.com) by idunn.apache.osuosl.org (ecelerity 2.1 r(10620)) with ESMTP id 09/00-06697-7B621054 for ; Fri, 08 Sep 2006 01:15:53 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k888EWI5016301 for ; Fri, 8 Sep 2006 04:14:32 -0400 Received: from radish.cambridge.redhat.com (radish.cambridge.redhat.com [172.16.18.90]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k888EVk2014140 for ; Fri, 8 Sep 2006 04:14:32 -0400 Received: from radish.cambridge.redhat.com (localhost.localdomain [127.0.0.1]) by radish.cambridge.redhat.com (8.13.7/8.13.7) with ESMTP id k888EV24014572 for ; Fri, 8 Sep 2006 09:14:31 +0100 Received: (from jorton@localhost) by radish.cambridge.redhat.com (8.13.7/8.13.7/Submit) id k888EUKZ014570 for dev@apr.apache.org; Fri, 8 Sep 2006 09:14:30 +0100 X-Authentication-Warning: radish.cambridge.redhat.com: jorton set sender to jorton@redhat.com using -f Date: Fri, 8 Sep 2006 09:14:30 +0100 From: Joe Orton To: dev@apr.apache.org Subject: Re: API to prevent further allocations from a pool? Message-ID: <20060908081430.GA13690@redhat.com> Mail-Followup-To: dev@apr.apache.org References: <20060907160310.GA6946@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N On Thu, Sep 07, 2006 at 12:39:57PM -0400, Jeff Trawick wrote: > On 9/7/06, Joe Orton wrote: > >On Thu, Sep 07, 2006 at 11:22:35AM -0400, Jeff Trawick wrote: > >> It would be cool for the MPM to be able to lock the pool once it is > >> ready to start serving requests so that if any errant module tries to > >> use pconf, pchild, etc. it will crash immediately instead of > >> introducing memory corruption under load. (Even if the module author > >> is "clever" and uses a mutex around the pool use, that assumes she is > >> the only person in the world to have that idea.) > > > >If done "#if APR_POOL_DEBUG", I think this would be useful. > > People who don't know pools don't know APR_POOL_DEBUG either ;) *You* can still run the suspect modules through a stress test on a debug-enabled server build, right? > Is it just a performance concern which leads you to APR_POOL_DEBUG? Simply that this is a debugging aid and as such it seems sufficient to add it to the debug code and leave the production code alone. But to make a strong API guarantee I think this would need to use atomic operations anyway, which means the performance hit (mutexes on some platforms) would indeed be way too high for the pool allocation critical path, I think. Regards, joe