httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stanley Gambarin <stanl...@cs.bu.edu>
Subject Re: [PATCH] (take 1) reliable piped logs
Date Mon, 22 Sep 1997 23:28:39 GMT


On Mon, 22 Sep 1997, Dean Gaudet wrote:
> 
> > > > inline pool *mem_init() 
> > > > {
> > > > 	return (make_sub_pool(NULL));
> > > > }
> > > > inline void memory_destroy(pool *p) 
> > > > {
> > > > 	destroy_pool(p);
> > > > }
> > > > 
> > > > which would allow external modules to use  Apache memory pool stuff,
> > > > without any sideeffects.  If pepople are interested, say "Arg" and
> 
> I don't see why it's a problem for you to call make_sub_pool(NULL) ...
> since you're in a separate process.  This is what the API allows you to
> do.  Or am I still missing something?
> 
> Dean
> 
> 
	It maybe my misunderstanding, but I thought that the whole
idea behind API was to isolate module developer from the internal
implementation.  I do realize that I can call the function myself, 
however, should the pool handling change, it will force
incompatibility across modules, which really sucks.  I am currently
running in the same problem, where the changes are made to the 
server forcing source changes, resulting in maintaining of multiple
copies of the same module for each version of Apache server.  I do
realize that some of the changes are necessary, however, it does 
not make my life any easier (this is why a clear and fixed API is
a necessity).  Also, if all the system() functions are to be 
replaced by the ap_ or os_ counterparts, this would also make my life
a bit easier (as it will avoid stuff like just happened with ap_md5())
which forced yet another copy of the module to maintain.  Providing
some sort of abstraction layer for ALL system functions used in 
Apache would be a nice addition (especially for module developers)
Just some of my whining...
					Stanley.


Mime
View raw message