httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject [s/rant/patch/] os/cannonical error
Date Wed, 04 Oct 2000 06:09:46 GMT

Ok... here's the proposal, without the massive changes required to
actually replace every occurance of the original tests throughout
the code.

I've simply taken [most] of the canonical_error conversions and
shifted them to their appropriate macro.

Unix... please pay attention to the APR_ERROR_IS_EAGAIN and APR_EAGAIN
declarations, and their relationship to EAGAIN and EWOULDBLOCK.  
I could have blown it completely, but I gather this is correct.

OS2... I gathered and inferred what I could from the sources.  It really 
illustrates the cpu operations flaw of the original design as used by OS2.

Win32... I've barely touched the list, the error codes need review.
Stolen (almost completely) from OS2.  However, this illustrates the
simplicity of using the system's own error codes 'in place', without
any transform.

I can keep or lose APR's own status/error code macro tests, I simply
implemented every code as a macro.  Not sure here if something will
later pop up as an issue (e.g. an APR_EOF equivilant result code.)
Please vote on these separately from the canonical/os errors proposal.

And I certainly don't mind offloading or customizing this file by
platform (all that EAGAIN/EWOULDBLOCK could be configure'd in, 
for example.)  But since we don't expect users to step into their
platform's include tree, we need to think this through.  I'd like
to simply get it committed, then we can review.

Without any objections, I'll commit tommorow night or Wednesday..

Bill



> -----Original Message-----
> From: rbb@covalent.net [mailto:rbb@covalent.net]
> Sent: Wednesday, September 20, 2000 1:45 PM
> To: new-httpd@apache.org
> Subject: Re: [rant] os/cannonical error
> 
> 
> 
> This makes sense to me.  Of course, instead of the 500 line case
> statement, we have 500 lines of #defines.  Hmmmmmm.......   
> Those #defines
> could be in a simple per-platform header file, so it wouldn't 
> really be
> that bad.
> 
> +1
> 
> Ryan
> 
> On Wed, 20 Sep 2000, William A. Rowe, Jr. wrote:
> 
> > The last post just reminded me...
> > 
> > MUST we be adding cpu cycles to flip OS errors to native ERRNO
> > values in canonerr.c!?!  I'm looking forward to the day we have
> > a 500 condition-long switch block.  -not-.
> > 
> > I've suggested a very long time ago... let's take the EAGAIN
> > error just for kicks.  Why not a simple, compile-time macro to
> > deal with this.  Unix:
> > 
> > #define APR_IS_EAGAIN(e) ((e) == APR_EAGAIN)
> > 
> > Gee.  No CPU cycles wasted.  Windows?
> > 
> > #define APR_IS_EAGAIN(e) (((e) == APR_EAGAIN) || (e) == 
> WSAEWOULDBLOCK)
> > 
> > Ohhh... a whole extra few cycles.  Not an entire switch block full
> > of them, however.
> > 
> > If we realize a new API specific error on any platform... 
> just add it
> > to the (now growing) list of equivilant errors.  Keep APR's 
> list rather
> > short and sweet, and track the dozens of 'equivilant' errors using
> > the macro.  Very readable, I think...
> > 
> >     if (stat != APR_SUCCESS && 
> >         !(APR_IS_EINPROGRESS(stat) ||
> >             APR_IS_EAGAIN(stat))) {
> >         apr_close_socket(sock);
> >         fprintf(stderr, "Could not connect: %s (%d)\n", 
> > 		apr_strerror(stat, msgbuf, sizeof(msgbuf)), stat);
> > 
> > I don't think this is all that ungodly... but a 500 error 
> case statement
> > will be, someday in the (near?) future.

Mime
View raw message