httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Marr <gr...@alum.wpi.edu>
Subject RE: logging APR errors
Date Mon, 17 Jul 2000 21:00:57 GMT
At 01:47 PM 07/17/2000 -0700, rbb@covalent.net wrote:
> > I know this is far from thought out, never mind designed.  But if we have a
> > message, we are prepared to wire the message.  If we don't, we let the
> > functions we call and the function that called us work all that out.
>
>The biggest problem I have with this, is that now the app is logging the 
>error sometimes, and APR is calling back into the app to log it other 
>times.  This is bad.  Plus, we don't have just one function that we can 
>push to the stack, we have at least two, plus a NULL for no error.

Why is this bad?  You might just as well say that sometimes the app logs an 
error, and sometimes not.  If you're worried that much about it, have 
Apache always log the error.  If the APR function has additional 
information it can give the application, that will get logged as well.

>What is wrong with just adding a couple of more error values?

It causes changes to mainline code, which you said was unacceptable, for 
one.  It also assumes that all the relevant information about the error can 
be stored in an int.

>If we want, we can even do something like:
>
>ap_sendfile(...)
>{
>setsocketopt(...)
>         return (AP_SENDFILE_SOCK_OPT_ERROR+errno)
>...
>}
>
>This will give us as much information as we could possibly want.

Ok, so now you have to make sure that for all values of errno that could be 
set after calling setsocketopt on all platforms, that 
AP_SENDFILE_SOCK_OPT_ERROR + error doesn't collide with another error value 
that could be returned by ap_sendfile().


Mime
View raw message