Mailing-List: contact new-httpd-help@apache.org; run by ezmlm
Precedence: bulk
Reply-To: new-httpd@apache.org
Message-ID: <009b01bf9896$5a58f940$0a1aa8c0@jetnet.co.uk>
From: "David Reid" <dreid@jetnet.co.uk>
To: <new-httpd@apache.org>, <trawickj@bellsouth.net>
References: <200003280153.LAA29842@silk.apana.org.au>
 <200003280236.VAA01302@k5.localdomain>
Subject: Re: cvs commit: apache-2.0/src/lib/apr/dso/os2 Makefile.in dso.c
 dso.h
Date: Tue, 28 Mar 2000 10:15:39 +0100
MIME-Version: 1.0
Content-Type: text/plain;
	charset="Windows-1252"
Content-Transfer-Encoding: 7bit

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