httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dean Gaudet <dgau...@arctic.org>
Subject Re: memory allocation (was Re: Why bother with APR?)
Date Tue, 21 Sep 1999 15:21:42 GMT
On Tue, 21 Sep 1999, Rodent of Unusual Size wrote:

> Dean Gaudet wrote:
> > 
> >                    a pool is just a place to hang cleanups in
> > my opinion
> 
> Well, my opinion, at least, differs.  That happens to be a
> feature of pools to my mind, but not their raison d'ĂȘtre.

ok, would you agree that memory and child subprocesses are examples
of resources?  these happen to be the only two resources (1.x) which
require a little extra state information on a per-pool basis.

would you agree that pools are used when resources need to be tracked,
and destroyed as a group?

would you agree that palloc is a memory allocator with the property
that allocations can only be freed as one large unit?  this is a common
abstraction by the way -- it's present in other programs, under different
names.  most frequently present for fixed-size allocations, but i digress.

you guys notice a new abstraction which is useful -- you notice that
it's useful to abstract per-pool state.  that's great, it is.  in fact,
if you study the 1.x pools you'll see we already have two examples of
per-pool state: palloc and child subprocesses.  but you didn't notice
that, so you went about creating a structure which looks like this:

    struct context {
	abstract per-context state information;

	struct pool {
	    abstract resource cleanup information;

	    not abstracted palloc allocator information;
	    not abstracted subprocess information;
	};
    };

at this point it should be obvious that those two resource trackers should
use the abstract per-context state information.  and you're left with:

    struct context {
	abstract per-context state information;

	struct pool {
	    abstract resource cleanup information;
	};
    };

ok, maybe pools are going to be used on their own somewhere without the
context.  but, that isn't the case.  ryan has just gone through the
code and done a search and replace changing context to pool.  there's
absolutely no reason for the pool to exist on its own.  so in fact
perhaps you'll all realise that a logical next step is this:

    struct context {
	abstract per-context state information;
	abstract resource cleanup information;
    };

bye bye pools.  in retrospect you might realise now that you've essentially
forced every single apache author to learn a new concept... when really,
only 1% of them (us mainly) needed to care about the per-context state
information.  furthermore, you've changed the name from something with
a lot of overloaded meaning, pool, but with a lot of history within apache,
to something which has even more overloaded meanings: context.  this is
a step backwards in readability.

*and furthermore* the code now has bloody confusing crap like this
segment spread all over the place:

    ap_context_t *tmp;

    ap_create_context(p, NULL, &tmp);
    ...
    ap_destroy_pool(p);

you guys get 10 points for figuring out the per-pool state abstraction.

but you lose about 100 points for the boneheaded moves which followed
that.

Dean


Mime
View raw message