httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dean Gaudet <>
Subject Re: ap_ prefix to funcs (was: Re: patches from "Paul B. Henson")
Date Thu, 04 Sep 1997 04:04:07 GMT
Yeah pools can/should be abstracted.  The application linking against
libap using pools should provide block_alarms()/unblock_alarms().
Otherwise a stub in libap should provide dummy versions.


On Wed, 3 Sep 1997, Paul Sutton wrote:

> On Tue, 2 Sep 1997, Dean Gaudet wrote:
> > Given that these other systems expect to be linked against apache ... I'm
> > not sure why they have this problem.  Rasmus? 
> > 
> > But it would be cleared up a whole bunch I think if we created a libap.a
> > which contained all of our support functions that exist for OS
> > compatibility and whatnot.  Then php could include -lap while testing for
> > functions it needs. 
> Yeah, sounds like a good idea. One question that I've been pondering
> recently is how much the OS abstractions should know about Apache. Ideally
> they shouldn't have to know anything about Apache at all, but *many* of
> the things that would be nice to abstract (such as the recent
> os_canonical_filename) need to do memory allocation, so they need to know
> about pools. 
> So should the functions and headers is os/* know about pools (i.e. include
> "alloc.h") or not? If they do know about pools it makes abstraction much
> easier because the functions (such as os_canonical_filename) and their
> prototypes can be stuck into os.c/os.h as necessary. If the os files do
> not know about pools then everything has to be done via defined constants
> then the OS specific code stuck into a file in main, which is not so
> neat. 
> On the other hand, the os abstractions may in the future be used for other
> support programs (e.g. htpasswd) which do not need to know about pools. 
> Umm. 
> I'm leaning towards letting os/* know about pools. Then we can move all
> the OS-specific stuff out of conf.h into os/*/os.h, put #include "os.h"
> into conf.h, and then actually abstract things.
> (Incidently os_canonical_filename currently *does* work despite being in
> os/win32, but only because it is compiled as part of ApacheCore. It won't
> work if a similar (and it is necessary) os_canonical_filename is added to
> os/emx/os.c).
> //pcs

View raw message