httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: lib/aputil
Date Tue, 28 Nov 2000 15:05:54 GMT

> And apu_dbm is quite useful outside of Apache. I intend to use it in
> Subversion. (admittedly, from an Apache module :-).

That is not outside of Apache then.  Please, how is it useful completely
separate from Apache.

> > It is using
> > apr_pools, but I'm not convinced pools makes much sense here in any
> > context other than Apache.
> What?!! Pools are kick ass. How can you possibly say they don't make sense
> for anybody but Apache?

I didn't say that.  I said that pools don't make sense for a database
outside of Apache.  I think pools do make sense outside of Apache, but I
disagree that they are valid everywhere.

> > Pools are a great memory management scheme,
> > but what are they buying us here?
> When mod_dav uses apu_dbm, and the request ends, I want to be sure that all
> of the SDBM-created files and locks and memory are closed/discarded. That is
> what pools are for, and which is why they are passed into SDBM.

But that is INSIDE of Apache, and this can be handled more cleanly without
putting the pools into SDBM.  Apache 1.3 had to solve this problem, and it
was solved by registering cleanups for those structures with the correct
pool.  What you have done here, is to pollute a database with pools so
that Apache works the way you want.  I still don't see what this is buying
us at all.  Following this logic, we should also probably put pools into
expat and pcre, because when the request is done we want to make sure all
of their pieces go away too.  I seriously disagree with putting pools into
a database; -1 unless you can provide a place that having pools in the
database is useful that is completely separate from Apache.

> > As far as I can tell, the pool is
> > required because we are using our own hacked version of sdbm that requires
> > pools.  But why did we ever do that to sdbm?
> Because that is our copy of SDBM, and it made a ton of sense to APR-ize the
> darn thing. There was some hacked up stuff in there to deal with different
> platforms, which is now gone. We also get the benefits of pools. We get
> portability of SDBM, which is cool because we can always use it as a
> fallback DBM whenever one isn't available in the operating system. (note
> that mod_auth_dbm uses SDBM on Win32)

Okay, I'm confused.  We get the portability of SDBM, but we had to modify
it to make it portable?  I don't think pools make much sense in a database
unless you are in an Apache-like program.  I have a small problem with
distributing SDBM with Apache, only because it increases the size of the
tarball, and it available from other sources, but I am willing to deal
with that.  I have a HUGE problem with modifying SDBM to use pools when it
isn't necessary.  I have SDBM in one of my external modules, and not the
version we put into Apache 2.0, cleaning everything up works just fine
without pools.

> > The only other place we use
> > the pool, is to allocate a structure that could easily be allocated
> > outside of the function.
> Eh? It is also used for files within SDBM. Since apu_dbm could call SDBM, it
> needs to pass a pool. The structure you refer to (I presume apu_dbm_t) is an
> internal, opaque structure. It should not be exported, which means it must
> be internally allocated.

You are correct, the apu_dbm_t structure is internal, the fact that the
structure name is type-safe made me think it might be used outside this
file.  This must be internally allocated, but it doesn't need to be
allocated out of a pool.  Export a routine to clean up the structure, and
Apache could use pool cleanups to acheive the exact same results without
requiring us to modify SDBM.

> > Regardless, this REALLY needs to become a full package ASAP,
> What is wrong with a simple Makefile? Why do we have to autoconf the darn
> thing, or make it standalone, or whatever?

Because you want to put more there.  The way you have it structured right
now, this may as well have all stayed in src/ap.  Moving it to src/lib
doesn't get you anything at all.  If you are going to put this code in
src/lib, then it should be able to stand on its own outside of Apache
IMHO.  Also, this is part of the reason that needs to be so
ugly.  If every package in src/lib is a separate package that can handle
make clean and make distclean on their own, then we could stop the find
for Makefile at the src/lib/foo directory, instead of having to
special-case the packages that are full packages.

> Let's get our work done, not spend time on packaging something that is a
> *long* ways from ever being split from Apache. We knew up front that APR was
> going to be separated, so we spent a lot of time packaging it. Doing the
> same for SDBM or aputil is just wasted effort.

Then it doesn't belong in lib, it belongs in ap.  I assume that as we move
stuff into aputil that we will create directory hierarchies.  If not, then
just leave everything in ap.

> At least everything in src/ap/. Possibly a good number of util_* that is
> sitting in src/main/ (e.g. the XML stuff, maybe some conftree stuff, things
> like "getword" and friends, etc)

The conftree stuff is pretty Apache specific, and should not be removed
from Apache.  I also dislike re-organizing the code right now.  We are
getting close to a beta, and now we have to deal with build issues again.

Ryan Bloom               
406 29th St.
San Francisco, CA 94131

View raw message