httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: logging APR errors
Date Fri, 14 Jul 2000 20:15:32 GMT
On Fri, 14 Jul 2000, Bill Stoddard wrote:
> > On Fri, 14 Jul 2000, Greg Ames wrote:

> > The correct way to handle this was veto'ed at the very beginning of
> > development for APR.  The correct method was to have the status be a
> > complex bitmap which we could use to determine where we actually failed.
> >
> > Since we no longer have that option, we have to define different APR error
> > codes for the different failure conditions inside of ap_sendfile.
> >
> There are other techniques available as well. Look back a couple of months in this list
for Jeff
> Trawick's posts on this exact topic. One method mentioned at the time is to register
an application
> specifc (Apache in this case, or perhaps an individual MPM) error handling function with
APR at init
> time. This function is called to log the specific failure (function call, failing system
call, line
> of code, message string, etc.). If Apache is not interested in greater visability into
APR failures,
> it simply does not register an error handler function (which implies the APR wrapper
that calls this
> function must be able to handle a NULL function pointer). This is simple and very extensible.
> sense?

Take a look at the archives from a year.  The decision from back then, was
to return error values to the calling program.  Having every APR program
be able to register an error logging function adds yet another if
condition to EVERY single APR function.  Many of those functions have
multiple error paths.  This means that we get multiple if's for every APR
function.  People are already complaining that APR isn't performance
aware, and now we want to slow it down more.

The correct way to solve this was put forth about a year and a half ago.

1)  Use a rich error code, which gives all the information we could
possibly want.  We provided a bitmask that would have worked for these

2)  Use the context to return an error string.

Both of these were suggested and rejected.  I am very much against hacking
an error function into APR now.  I would rather delay 2.0, and put in the
correct solution (one of the two above), than hack in the wrong solution.


Ryan Bloom               
406 29th St.
San Francisco, CA 94131

View raw message