httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <>
Subject Re: [VOTE] ap_r* model.
Date Fri, 02 Mar 2001 09:18:44 GMT
On Thu, Mar 01, 2001 at 02:17:34PM -0800, wrote:
> On Thu, 1 Mar 2001, Greg Stein wrote:
> > In ADDITION: There is a coupling across subsystems introduced by the r->bb
> > mechanism. As a result, they will have ordering issues unless they *also*
> > pay attention to what other pieces are doing.
> This doesn't exist at all if the sub-systems use ap_r.

Not all subsystems *are* going to use ap_r*. The whole point of "subsystem"
means it is an independent unit. Coupling means that the subsystem is no
longer independent -- it is "coupled" to what its callers/users do.

If it was independent, it could choose to reimplement its output in terms of
brigades for better performance. Maybe it keeps a whole bunch of them
around, ready for delivery, and chooses one to shoot down the pipe.

This cache of brigades is quite likely. Consider the mod_cache_file module.
For each file, it could allocate a brigade from its cache pool (ensuring the
brigade won't die with the request). It then creates a bunch of mmap or file
buckets with a refcount==1. When a file needs to be delivered, it shoves the
mmap bucket and a new EOS bucket into the brigade and delivers it. (maybe it
has a cache of EOS buckets?)  In this case, it is using custom brigades. Now
what happens if we expose "deliver a cached file" to other portions of
Apache so that everybody can reuse that nifty little cache? For example,
maybe mod_include wants to use it for #include "page_header".

Coupling reduces the flexibility of subsystems. You either disallow the
flexibility, or you patch up the potential errors with things like

> At least not anymore than it does for the OLD_WRITE filter.

There are no ordering or coupling problems with OLD_WRITE.

Module authors, utility functions, subsystem developers, whatever ... they
can choose the output mechanism that is best suited for the problem at hand.
They have no worries about what the next guy is doing, or what their caller
may be doing.

> > > disadvantages:
> > > 	This is a special filter, that solves the buffering problem in a
> > > way completely unrelated to ap_f*.  This means that we have to maintain
> > > two independant solutions.
> >
> > Untrue. I have said MANY TIMES that the OLD_WRITE will also use ap_f*. The
> > current implementation predates ap_f*.
> Which will still be implemented as a filter.  While the buffering itself
> may use ap_f* under the covers, the maintenance of the actual filter is
> still an issue.

Everything is code which needs to be maintained. Any solution to create
ap_r* compatibility requires some code. What is the point?

I was responding to your comment about "buffering ... unrelated to ap_f*".
Totally false. The OLD_WRITE filter is intended to use ap_f* now that they
exist. Soon after OLD_WRITE appeared, and we were talking about adding
ap_f*, I said right then: OLD_WRITE should use those functions when they
exist. The custom buffering in there was designed/coded without their

> > > 	If a filter is added in between the handler and the OLD_WRITE
> > > filter, then the performance improvement disappears.
> >
> > While true, it is not a realistic scenario. As I've stated before, the
> > OLD_WRITE filter should use a filter type such as:
> >
> >   #define AP_FTYPE_INTERNAL 0 /* reserved for Apache internal filters */
> >
> > Thus, nobody is/should be using that filter type, and no filter will precede
> > the OLD_WRITE filter.
> I am thoroughly against this proliferation of filter types, and have been
> since the beginning.  What happens when Apache needs something to go
> between the OLD_WRITE filter, and another filter?  We create another
> filter type?

That is a red herring.

The need for Apache to have filtering types is unrelated to the problem at
hand. You and I discussed this need at ApacheCon. If you want to discuss the
merits of filter types, then start a new thread, but it should not be mixed
in with this discussion.


Greg Stein,

View raw message