apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ryan Bloom" <...@covalent.net>
Subject RE: cvs commit: apr/poll/unix poll.c
Date Fri, 02 Aug 2002 20:58:25 GMT
> From: William A. Rowe, Jr. [mailto:wrowe@rowe-clan.net]
> 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
> > >     We cannot ignore alloca/malloc failures.
> >
> >We generally ignore memory allocation errors of all kinds in the
> >and APR.  The general thought has always been that if you are
> >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
> are different beasts altogether.

Huh?  We don't have any logic to tell apr_palloc how to die.  The
assumption is that if the server runs out of memory, then apr_palloc
will return NULL, and the code will seg fault.  The exact same
assumption can be made for malloc and alloca.  There is no logic in
apr_palloc which should actually cause the seg fault AFAIK, the seg
fault is expected in the code that calls apr_palloc.


View raw message