httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan Bloom <...@raleigh.ibm.com>
Subject Re: [APR] Universal return syntax
Date Tue, 26 Jan 1999 18:12:58 GMT
> >So, here is the thought for how to fix this.  Each thread gets an
> >APRErrStruct when the thread is created.  Ignore how it is attached to the
> >thread, that is another discussion.
> >
> >struct APRErrStruct {
> >	Error Class
> >	Error Code
> >	Descriptive Text
> >}
> >
> >The error class is an enumerated type, that is a small set of possible
> >outcomes, from everything is great, to SIGSEGV impending.
> 
> I lean toward a structure.

I don't see a need for a structure.  This should be a very simple check,
that says what kind of error do I have.  This is the first value to check
on returning from a function.  If the function worked properly, then the
class will be APR_SUCCESS (or something like it), and you can move on.  If
the class is APR_WARNING, then maybe we want to output an error message,
or maybe we don't, depending on the LogLevel.  If the class is
APR_FAILURE, we probably want to output some message.  The the class is
APR_UHOH, then we have a seg fault coming, and lets do some cleanup.  The
whole idea of the cleanup, is to get us a quick and dirty idea for where
we are, so we can make an intelligent decision for what to do next.

> 
> The structure's complexity needs to make a strong case for it's self
> since it's going to tax a lot of code.  Dean's "why more than errno"
> being the strongest instance of that demand.

That's one of the nice things about this.  For places that don't need more
than an success/failuer, our class code gives us that with a minimum
amount of comparisons.  If we actually want to know what happened, we can
look at the error code.

> 
> I like getting some descriptive text ASAP, close to the error, a lot!

We can also pass an Or'ed value down, to determine if we should bother
creating the error text.  For example, for a warning, we can tell APR not
to create the error text, if the Loglevel is just going to ignore it
anyway.  This will take some fleshing out, but it shouldn't be hard to do.

> 
> I don't think I have a strong intuition for what error_class get's
> used for.  The analogy to the parameters of the logging routines is
> strong.  Logging, dispatch during stack unwind?  Let's set that aside
> for the moment.

See above.

The analagy to the Apache loglevel is right on.  This value is there,
because we will ave a very small set of possible values for error class,
so we can check them easily.  We can also use the error classes to
determine if we should generate a message or not.
> 
> >The error code, is an actual error code, to tell the program what is
> >happening.  No more memory, could not open file, etc.  These are specific
> >to the Sub-system.
> >
> >The text, is an actual text string that the sub-system generates.  This
> >has any data that might be useful to diagnosing the problem.
> 
> Yes, I like that.  I remain hopeful we will get alloc core functionality
> down REAL low so this text can alloc from a the thread's global
> heartbeat pool.
> 
> >All functions get passed this structure.
> 
> I rather just put it in the thread state, along with the thread's
> "pid", global pool, and heart beat pool.

I mis-spoke.  I didn't want to deal with how this structure gets passed
around in that message, because we still need to tackle the idea of pools,
or contexts, or thread-local data.  The idea was that each function had
access to write to that structure.

Ryan

_______________________________________________________________________
Ryan Bloom		rbb@raleigh.ibm.com
4205 S Miami Blvd	
RTP, NC 27709		It's a beautiful sight to see good dancers 
			doing simple steps.  It's a painful sight to
			see beginners doing complicated patterns.	


Mime
View raw message