apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <...@covalent.net>
Subject Re: cvs commit: apr/memory/unix apr_sms.c apr_sms_trivial.c sms_private.h
Date Sun, 08 Jul 2001 00:27:52 GMT
On Sat, 7 Jul 2001, Justin Erenkrantz wrote:

> On Sat, Jul 07, 2001 at 04:01:35PM -0700, dean gaudet wrote:
> > what's it really matter?  trying to clean up from OOM is near impossible.

It doesn't matter if it's impossible or not.  The problem is that we are
in a library, so we can't just write to stderr by default.  You have no
way of knowing what stderr is, or that it even exists.

> Which brings me back to my original question: "Why do we have an abort
> function?"  As you said (I was originally thinking this, but admittedly,
> I didn't bring this up), we can't do much.  About the only thing we can
> do is exit.  We *might* be able to make a log entry somewhere, but that
> depends if we need memory to do the printf or whatnot.

The point is that the original code from Apache 1.3 wrote a message to
stderr, and aborted.  The new code, has that option, but the default is to
return an error condition to the caller.  Again, you can't just write to
stderr, because you don't know that stderr even exists anymore.

> And, if palloc returns junk - NULL or non-NULL, we're bound to segfault
> at some point - which takes care of our process anyway.  Error-checking
> is something that we pointedly avoid doing in APR.
> I'm not still sure what the abort function gets us.  -- justin

The simple ability to let the program decide how to handle this error
condition.  This was pain-stakingly decided over a year ago, and before we
decide to take it out, please go back and read the mailing list archives
for November 1999.

Apache wants to write an error message and abort.  I will -1 having a
general purpose library do that by default, because it is VERY
inconsiderate to the calling program.  A general purpose library must
allow the program to know what is going on before it just dies.

I don't care if 99% of the time it is impossible to recover.  This isn't
about recovery.  It is about not allowing the library to just kill the


Ryan Bloom                        	rbb@apache.org
Covalent Technologies			rbb@covalent.net

View raw message