APR Error Protocol - take 2.

[Ben Hyde <bh...@pobox.com>]

Dean points out this never made it thru and I see it was
do to a typo on my end.  - ben

---

Back to the error handling discussion.

Having stood back from this for a while I think we ought to
agree that: The errno protocol is the way to go.

If, as we go along, we want to enhance this with other cool things -
that's fine.  But I don't think we can agree to those things now.  We
badly need code.  Code will hold the nose of these discussions to the
grind stone.

Lots of fun things might be piled on - some of these I'm a fan of - but
let's defer them.
 - using throw for connection killing errors.
 - standard support for logging classification schemes.
 - standard error instance description schemes.
 - etc. etc.

To be specific this is my proposal.  

- The APR errno Error Protocol -

APR routines notify their callers that an error has occurred by
returning an exceptional value that is easily distinguished from their
usual return value.  This exceptional value is often -1, or zero.
When ever a routine returns it's exceptional value it must set a
positive value in errno.  Errno is thread/fiber local storage.
Symbol names for all errno values are enumerated in apr_errno which
includes the usual unix errno.h.  APR client code may allocate
additional errno values in the region above 4000.  Errno is of
type int, i.e. it's size is compiler/platform specific.

It is entirely appropriate for routines to capture errors encountered
by their subroutines and handle them by: ignoring, logging, marking
some data structure, or invoking an alternative error protocol.  Such
alternatives error handling approaches may appear in the APR routines.

 - ben

Re: APR Error Protocol - take 2.

[Ben Hyde <bh...@pobox.com>]

Rodent of Unusual Size writes:
>Ben Hyde wrote:
>> 
>> I'm not particularly afraid of a few well chosen globals:
>	:
>>     extern thread_state APACHE_TLS *current_thread;
>
>Well, I am.  Globals are evil in a portable runtime.

Why?

>APR isn't intended to be tied specifically to the Apache
>Web server.  

Is that relevant?

>Consider multiple modules using it, 

Ok, what about them?
>or
>an external API being linked in that also uses APR
>behind the scenes.

Ok, what about it?

Obviously I'm not getting your point.  - ben

Re: APR Error Protocol - take 2.

[Rodent of Unusual Size <Ke...@Golux.Com>]

Ben Hyde wrote:
> 
> I'm not particularly afraid of a few well chosen globals:
	:
>     extern thread_state APACHE_TLS *current_thread;

Well, I am.  Globals are evil in a portable runtime.
APR isn't intended to be tied specifically to the Apache
Web server.  Consider multiple modules using it, or
an external API being linked in that also uses APR
behind the scenes.
-- 
#ken	P-)}

Ken Coar                    <http://Web.Golux.Com/coar/>
Apache Group member         <http://www.apache.org/>
"Apache Server for Dummies" <http://Web.Golux.Com/coar/ASFD/>

Re: APR Error Protocol - take 2.

[Ben Hyde <bh...@pobox.com>]

Rodent of Unusual Size writes:
>I personally consider errno to be evil, almost entirely
>because of the locality and reentrancy issues.  

In this case new is now more evil.

>And someone
>(Lars?  Martin?) commented on the APR draft not mentioning
>pools.

Some of alloc.c (maybe all of it) belongs very low down in APR.

>These two may actually be related. ...
>The context structure  ...
>I think that's enough to start discussion..

I'm not particularly afraid of a few well chosen globals:
    
    typedef struct process_state_s {
        ap_pool *global_pool;
        ap_pool *configuration_pool;
        ...
      } process_state;
    
    typedef struct thread_state_s {
        process_state *process
        ap_pool *thread_pool;
        ...
      } thread_state;
    
    extern thread_state APACHE_TLS *current_thread;
    
But today I can't see any particular advantage to moving errno
into thread_state.

   - ben

Re: APR Error Protocol - take 2.

[Rodent of Unusual Size <Ke...@Golux.Com>]

I personally consider errno to be evil, almost entirely
because of the locality and reentrancy issues.  And someone
(Lars?  Martin?) commented on the APR draft not mentioning
pools.

These two may actually be related.  When we were discussing
a lot of the stuff that went into the draft, we acknowledged
that pools are necessary, crucial, central, whatever you want
to call them.  One of the things we talked about (it was my
POV, so I'm fuzzy on the alternatives discussed ;-) involved
wrapping a pool within some sort of APR-specific context
structure.  The context would be created by a 'apr_begin()'
call, and destroyed by an 'apr_end()' call.  Destroying a
context would trigger the usual pool semantics (destruction
of subcontexts, cleanup activations, ...).

The context structure would be passed around by pointer, and some
fields within it could be public or could be accessed
through some sort of method interface.  Contexts could have
child contexts, and so on.

The errno concept could be fit in as a field in the context
structure.  Using a more-general structure than just a *pool
allows us to add things like buffering defaults for files
popened() with that context, or the bounded/unboundedness of
the pool, or signal handlers, or whatever.

I think that's enough to start discussion..
-- 
#ken	P-)}

Ken Coar                    <http://Web.Golux.Com/coar/>
Apache Group member         <http://www.apache.org/>
"Apache Server for Dummies" <http://Web.Golux.Com/coar/ASFD/>