Return-Path: Delivered-To: apmail-apr-cvs-archive@apr.apache.org Received: (qmail 43742 invoked by uid 500); 2 Aug 2002 20:38:08 -0000 Mailing-List: contact cvs-help@apr.apache.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Reply-To: dev@apr.apache.org Delivered-To: mailing list cvs@apr.apache.org Received: (qmail 43718 invoked from network); 2 Aug 2002 20:38:06 -0000 Errors-To: Message-Id: <5.1.0.14.2.20020802144320.02f27898@pop3.rowe-clan.net> X-Sender: wrowe%rowe-clan.net@pop3.rowe-clan.net X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 02 Aug 2002 14:44:40 -0500 To: From: "William A. Rowe, Jr." Subject: RE: cvs commit: apr/poll/unix poll.c Cc: , In-Reply-To: <000c01c23a56$bc5e2480$3600000a@KOJ> References: <20020802185153.85428.qmail@icarus.apache.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N At 01:59 PM 8/2/2002, Ryan Bloom wrote: > > Modified: poll/unix poll.c > > Log: > > We safely ignore palloc failures [we can segv in the allocator]. > > We cannot ignore alloca/malloc failures. > >We generally ignore memory allocation errors of all kinds in the server >and APR. The general thought has always been that if you are actually >running out of memory or stack space, then your computer is hosed >anyway, and you are going to seg fault. Why can't we follow the same >rules here? apr_palloc can be told exactly how to die, the platform malloc and alloca are different beasts altogether.