httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rodent of Unusual Size <Ken.C...@Golux.Com>
Subject Re: SERVER_VERSION with OS
Date Tue, 21 Apr 1998 00:46:26 GMT
Dean Gaudet wrote:
> 
> On Mon, 20 Apr 1998, Rodent of Unusual Size wrote:
> 
> > Okey, fine - I think I understand now.  The only problem is that pconf
> > is static in http_main.  (ISTR discussions leading to this, so I'm not
> > questioning it.)  So how to use it in another source module?
> 
> You pass it in, just like almost every other function in the server takes
> a pool.

That doesn't help.  This routine is supposed to be callable from all
over the server, not just http_main.  And you wouldn't want a module
to pass in a pool that's temporary - that way lies SEGVs.  Unless you're
suggesting a separate routine that just lets these routines know about
pconf - which is inelegant.

table_add doesn't take a pool - it uses one already defined in the
table, hiding that detail from the caller, which doesn't need (nor
want) to know it.  This is the same sort of thing.  make_table
takes a pool because the table might live anywhere - but this
information will *always* live in pconf, so again passing a
variable that's always the same is inelegant.

> SERVER_VERSION doesn't have to be in the same file as SERVER_BUILT and I
> really don't want it there.  Like you say, SERVER_BUILT is regenerated and
> recompiled every time.

And SERVER_VERSION should be, too.  The server identity items should be
rebuilt every time the server is relinked, IMO.  I'd like to see
SERVER_VERSION and SERVER_SUBVERSION pulled out of httpd.h and put
into the identity file (currently buildmark.c), and accessed through
routines rather than directly as constants.

> > I haven't worked with pool cleanups before, and the documentation for
> > the routines hasn't been written yet :-), so: do they get declared once
> > and live forever, or each time the pool is munged?
> 
> (stick this into a doc file if ya want ;)

I will, thanks!

> They live until clear_pool() is called:  clear_pool(a) recursively calls
> destroy_pool() on all subpools of a; then calls all the cleanups for a;
> then releases all the memory for a.  destroy_pool(a) calls clear_pool(a)
> and then releases the pool structure itself.  i.e. clear_pool(a) doesn't
> delete a, it just frees up all the resources and you can start using it
> again immediately.

And after clear_pool you have to redeclare the cleanup?  So the cleanup
in this case should redeclare itself whenever it's called?

[snip]

Much clearer now, thanks!

#ken	P-)}

Ken Coar                    <http://Web.Golux.Com/coar/>
Apache Group member         <http://www.apache.org/>
"Apache Server for Dummies" <http://Web.Golux.Com/coar/ASFD/>

Mime
View raw message