From dev-return-5663-apmail-apr-dev-archive=apr.apache.org@apr.apache.org Wed Feb 06 19:21:56 2002 Return-Path: Delivered-To: apmail-apr-dev-archive@apr.apache.org Received: (qmail 22029 invoked by uid 500); 6 Feb 2002 19:21:56 -0000 Mailing-List: contact dev-help@apr.apache.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Delivered-To: mailing list dev@apr.apache.org Received: (qmail 22018 invoked from network); 6 Feb 2002 19:21:56 -0000 Message-ID: <3C618257.4020105@apache.org> Date: Wed, 06 Feb 2002 11:21:59 -0800 From: Ian Holsman User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.8+) Gecko/20020204 X-Accept-Language: en-us MIME-Version: 1.0 To: Ryan Bloom , dev@apr.apache.org Subject: Re: [PATCH] Free memory over a certain threshold back to the system References: <002b01c1af2f$f52ceb50$7f00000a@KOJ> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Ryan Bloom wrote: >>-----Original Message----- >>From: Justin Erenkrantz [mailto:jerenkrantz@ebuilt.com] >>Sent: Wednesday, February 06, 2002 8:59 AM >>To: Sander Striker >>Cc: dev@apr.apache.org >>Subject: Re: [PATCH] Free memory over a certain threshold back to the >>system >> >>On Wed, Feb 06, 2002 at 01:24:36PM +0100, Sander Striker wrote: >> >>>Hi, >>> >>>The 'high free' patch. I'm not sure we want this. >>>It may hide pools abuse problems. >>> >>Yeah, I agree we don't really want this. If we run out of memory >>with the normal pools, it means that the lifetimes are most likely >>incorrect. >> >>But, perhaps this could be a #define with a debug option? -- justin >> > > We definitely don't want this IMHO. If the pools are filling up, then > either pools are the incorrect model for your app, or they aren't being > cleared often enough. I would much rather not have this as an option at > all, because that just encourages people to use it. :-) > > Ryan > that's not the case at all. it will stop people using pool (and probably the APR) for application which have a large variance in their memory requirements over time. by not having this patch in your forcing the application to always grow over time, or at the least always stay at it's high water mark. Take for instance a message queue. normally the message queue is running at 2-3 messages in the queue..something borks up on the GET side causing the messages to pile up to 2k. the GET side then is fixed and empties the queue.. if we had the himem-free patch APR would be a great in here.. without it the size of the queue will allways be 2k instead of shrinking to 2-3. so.. i'm +1 on this patch > >