httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Reid" <dr...@jetnet.co.uk>
Subject Re: cvs commit: apache-2.0/src/lib/apr/dso/os2 Makefile.in dso.c dso.h
Date Tue, 28 Mar 2000 09:15:39 GMT
I have to admit that when I was looking for a problem with opening a file
having the error string would have been very helpful.  Perhaps Manoj's idea
of a get_error routine for every type is the best one?  It should make
finding the error easier and should be easy enough to implement.

I know Ryan doesn't like it though!

d.
----- Original Message -----
From: "Jeff Trawick" <trawickj@bellsouth.net>
To: <new-httpd@apache.org>
Sent: Tuesday, March 28, 2000 3:36 AM
Subject: Re: cvs commit: apache-2.0/src/lib/apr/dso/os2 Makefile.in dso.c
dso.h


> > One other thing, the OS/2 API call DosLoadModule() returns a valuable
> > piece of information on failure, the name of the module that failed to
> > load. When loading a DLL, that DLL may depend on a whole chain of other
> > DLLs, any one of which may fail. Knowing which one did can save a whole
> > lotta time.
> >
> > In 1.3, this information is put in the static error string for later
> > retrieval by ap_os_dso_error(). For APR I'm thinking that it could be
> > stored in the dso_handle_t for later retrieval by a suitable accessor
> > function.
>
> There are plenty of other situations where a particular os has special
> information which, if available, greatly simplifies problem
> determination.  OS/390, for example, has a secondary error indicator
> for every system call which provides more information about the
> error.  In many cases it is able to pinpoint the error.  This is
> particularly helpful in the case of configuration problems.
>
> We could invent ways particular to different data types for saving
> this information; we could add code to our favorite APR app for
> checking to see if any such information was available.
>
> An alternate idea (shot down very quickly a few weeks ago) would be
> for an APR app to give APR a function to call to record error
> information.  This dispenses with some issues completely, such as how
> to store the error info in the object for later retrieval and when the
> APR app should query the object for such info (all this multiplied by
> the number of objects that should support this type of information).
>
> One platform-independent aspect of the trace is the use of a text
> string to record the diagnostic information.  The text string could be
> used on any platform.  If get-last-error functions are added to
> various objects, they could return a text string for passing to
> ap_log_error().
>
> --
> Jeff Trawick | trawick@ibm.net | PGP public key at web site:
>      http://www.geocities.com/SiliconValley/Park/9289/
>           Born in Roswell... married an alien...
>


Mime
View raw message