httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Stoddard" <stodd...@raleigh.ibm.com>
Subject Re: Dr. Dobb's Article
Date Mon, 18 Sep 2000 19:46:32 GMT
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.

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.

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

Bill


>   I popped a patch up a couple of days ago that implemented
apr_canonical_error()
> for Win32. It maps a few of the more common Winsock errors into the APR
errors. It
> helped me when using aprlib so it might be a start.
>     G.
>
> rbb@covalent.net wrote:
>
> > That article was written back in like February of this
> > year.  Unfortunately, that is one of the problems with print media, they
> > take about six months to articles actually published.  :-(
> >
> > The bigger problem, is that Windows has not been fixed yet.  Windows
> > should be returning errno values, so that it can share code with other
> > platforms.  The GetLastError values should be APR_OS_START_SYSERR on
> > Windows.  If Windows continues to use plain GetLastError values as it's
> > return values for APR functions, then it cannot share any code at all with
> > other platforms, because those other platforms all expect errno
> > values.  But, I have explained all of this before, as have others (Jeff
> > Trawick I believe originally pointed out the problem), but nobody wants to
> > listen.
> >
> > Ryan
> >
> > On Mon, 18 Sep 2000, Greg Marr wrote:
> >
> > > Ryan, I read your recent article about APR in the October 2000 Dr.
> > > Dobb's Journal the other day. (The table of contents for the issue is
> > > at http://www.ddj.com/articles/2000/0010/0010toc.htm.  Unfortunately,
> > > they didn't publish the entire article online.)  Was that article
> > > written before the recent overhaul of the ap_status_t values?  It
> > > seemed like the article was saying that APR functions return errno
> > > values directly, and modify other values before returning them.  I
> > > thought that it ended up that Windows didn't return errno directly,
> > > but rather GetLastError().
> > > --
> > > Greg Marr
> > > gregm@alum.wpi.edu
> > > "We thought you were dead."
> > > "I was, but I'm better now." - Sheridan, "The Summoning"
> > >
> >
> >
_______________________________________________________________________________
> > Ryan Bloom                              rbb@apache.org
> > 406 29th St.
> > San Francisco, CA 94131
>
> ------------------------------------------------------------------------------
-
>


Mime
View raw message