Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Message-ID: <2961.146.101.134.65.994548686.squirrel@www.jetnet.co.uk>
Date: Sun, 8 Jul 2001 00:31:26 +0100 (GMT/BST)
Subject: Re: cvs commit: apr/memory/unix apr_sms.c apr_sms_trivial.c
From: <dreid@jetnet.co.uk>
To: dean-list-apr-dev@arctic.org
In-Reply-To: <Pine.LNX.4.33.0107071057580.10441-100000@twinlark.arctic.org>
References: <Pine.LNX.4.33.0107071057580.10441-100000@twinlark.arctic.org>
Cc: aaron@ebuilt.com, dev@apr.apache.org
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

> now... you guys may have palloc() returning NULL because you've put a
> layer of indirection into pools so that you can have pools on top of
> exotic storages.  if that's the case, then i really hope that one of
> those exotic pools is never passed to an httpd routine expecting a
> plain old memory pool.  'cause you'll waste a lot of cpu cycles putting
> NULL checks everywhere.

agreed

> i didn't look to see what happenned where the old abort() was. 
> anything which manages to squeeze out a log message (or exit(1) trying)
> is totally cool.

which is what we'll add.  i didn't see a default abort in the pools code, 
but i may not have looked hard enough, or i'd have added one already.  i 
guess it'll just dump a message to stderr and then exit, just like it does 
already in some routines.

david