httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: SDBM 2.0 'namespace protection'
Date Wed, 29 Nov 2000 23:16:57 GMT

> > Ummmm.....  Expat and PCRE haven't been namespace protected.  I personally
> > believe they should, but they aren't now.
> Those are external packages. It would be a bitch to keep them maintained if
> we heavily patched them. SDBM is an Apache-internal package, so we're free
> to make it as Apache-specific as we'd like.

This could be done with a simple script, and we don't update those
packages all that often.  I don't like the argument that this is too
difficult if it is the correct solution, and if it is the correct solution
for SDBM, then it is the correct solution for PCRE and Expat.

> It is located in lib/sdbm/ because it is a nicely modularized little
> library. The same goes for lib/aputil/ (assuming it grows like we've
> discussed so many times in the past).
> lib/ does not mean "external package"; it means "a chunk of modularized code
> that we can pick up into our build/link". That is a "lib" to me. If we want
> to formalize that we're pulling in external packages, then we should have a
> subdir named "xpackages/" or something. That isn't on Roy's list, but if
> people want that subdir, then we can easily have it added.

A chunk of modularized code also means that it can be removed from Apache
and still work and make sense.  Otherwise, I don't consider it modular.

> > The reason for losing those mods, is that pools are the wrong solution, as
> > is, I believe APR.  APR would be the correct solution if it wasn't tied to
> > pools, but it is.
> Why are pools wrong? You said the same about apu_dbm's internal type. What
> is wrong with using pools?! I really don't understand... :-(

Pools just aren't the correct solution.  Why do you want pools?  You say
it's to make sure we clean everything up, but that can be done in the
sdbm_close function, which can be called from a cleanup that is registered
in a wrapper function.  Taking a look at where we are using pools in sdbm,
it is just for sdbm_prep, which is only called by sdbm_open.  There is
nothing to cleanup (no cleanups are registered), we only ever allocate a
single structure out of this pool.  Why aren't we using malloc for
this?  This memory is essentially never freed as the code stands right
now.  If we weren't using pools, then the sdbm close function could free
the memory.

Pools are a great memory allocation scheme, but they aren't right for
every situation.  In this case, pools don't make any sense, because we
aren't using any of the features that pools give us.


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

View raw message