httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: cvs commit: apache-2.0/src/main http_core.c http_protocol.c util_filter.c
Date Thu, 14 Sep 2000 14:54:50 GMT
On Wed, 13 Sep 2000, Doug MacEachern wrote:

> On 13 Sep 2000 wrote:
> >   As a part of making adding this filter, I removed the ctx pointer from the
> >   ap_add_filter prototype.  The problem is that the core is the thing that
> >   is actually inserting the filter into the filter stack, but the core doesn't
> >   know how to allocate memory for each filter.  The solution is to have the
> >   filters themselves be responsible for allocating the ctx memory whenever
> >   it is required.
> wait, why not leave ctx in the ap_add_filter() prototype?  http_core can
> just pass NULL for the ctx.  i don't see AddFilter as being the only way
> to register a filter, other approaches may only know the context (which
> is something other than the filter name) at the time ap_add_filter() is
> called.  patch below puts it back, any problems with this?

-1 This is very bad.  This means that there are now two ways to add
filters to the stack, and filters will never know which one was
used.  That means EVERY filter that needs to have it's own data pointer in
the filter, needs this code at the top of the function (or wherever it
creates the structure):

    if (!f->ctx) {
        apr_palloc(p, sizeof(foo));

it is much cleaner for filter writers to just always do

    apr_palloc(p, sizeof(foo));

because there will never be any memory there when they are first called.

As for parameterization, it is a non-issue now.  Having the link to the
ap_filter_rec_t give the filter itself the filter name that was
used.  This means that the filter gets to decide what kind of memory to


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

View raw message