httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: Dr. Dobb's Article
Date Mon, 18 Sep 2000 19:59:13 GMT
On Mon, 18 Sep 2000, Bill Stoddard wrote:

> The patch is a start. The problem is actually much more pervasive though. I find
> it hard to get excited about canonicalizing errors returned by APR routines that
> Apache needs to be sensitive to (i.e, make a code path decision based on the
> error). The hack I've used in Win32 is to canonicalize the error inside the
> handful of routines of interest to Apache.

This doesn't work outside of Apache.  If we canonicalize inside of APR,
then we lose information.  There are only a few ways around this, and they
are require the use of either global memory or thread-private
memory.  That is all very non-portable, which means that in all error
conditions, we not only have to call the original APR function, but also
an APR function for thread-private memoryh.

> Canonicalizing the errors returned by APR in the routines of special interest to
> Apache (and there are maybe half a dozen or so) works acceptably in the sense
> that the information lost in these special cases is not significant. However,
> the hack violates the spirit of APR and the principle of least astonishment in
> that Apache may begin making code path decisions on return codes to routines
> that do not canonicalize their return codes.

No routine should be canonicalizing their return codes.  It is just that
simple.  By canonicalizing in some routines and not in others, things
break, and this horribly violates the principle of least astonishment.

> We are paying dearly in code cruftiness for the decision to not lose
> any error status inside APR (and, BTW, we are still falling down here
> in the current APR design as Jeff has pointed out on multiple
> occasions).  I would prefer an APR design that canonocalized

I thought we had solved all of those problems.  Jeff, where are there
still problems with the APR error values?

The code cruftiness is just not an issue.  We make like ten calls to
apr_canonize_error in all of Apache.  Dean raised this one a while ago,
and we all basically agreed it wasn't an issue.

> apr_status_t to Unix/Posix errno values and provided a facility for
> retrieving operating system specific errors in an auxillary call
> (e.g., apr_get_last_error() or apr_get_os_error()) in the cases where
> the info is needed. This is outside the mainline path so should not

It isn't necessarily a question of it being a performance hit, and it is
MUCH cruftier than what we are currently doing.  As I said above, this
would require either global or thread-local storage.  Everytime we wanted
to report a platform specific error (read: most times ap_log_error_core is
called) we would need to use thread-local storage.  The ap_log_error code
is called far more times that ap_error_canonize is currently called.

> cause a performance hit. Obviously, you need to save the data in
> thread local storage in the threaded APR case. Again, this shouldn't
> be a performance hit at all in the non-error case and performance in
> the error case is just not relevant.

I thoroughly disagree that this is not relevant.  It requires a call to
APR's thread local storage stuff throughout the server.  This also
requires adding a key variable to some structure in Apache.  I haven't got
a clue where it would be added, I guess we would need some thread
structure that we could hang off the request_rec, but that won't be


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

View raw message