httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Stoddard" <>
Subject Re: logging APR errors
Date Fri, 14 Jul 2000 22:05:40 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
> > specifc (Apache in this case, or perhaps an individual MPM) error handling function
with APR at
> > time. This function is called to log the specific failure (function call, failing
system call,
> > of code, message string, etc.). If Apache is not interested in greater visability
into APR
> > it simply does not register an error handler function (which implies the APR wrapper
that calls
> > function must be able to handle a NULL function pointer). This is simple and very
> > 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.

No. The function is just a way for APR to get access to the application's error logging. 
function would only be called on the error path to report error conditions to the application.
would not be called on the non-error path. If the application is not interested in error information
('extended' error information that is, beyond what is returned in ap_status) from APR, then
doesn't register the handler. This will not impact APRs performance (on the non-error path)
by even
one instruction, regardless of whether the handler is registered or not.

> 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.

There is more than one 'correct' way to solve this.

> 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
> cases.
> 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.

It's not a hack. You may not like it but that doesn't make it a hack.


View raw message