httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <>
Subject Re: [PATCH] Filter registration.
Date Tue, 25 Jul 2000 01:47:22 GMT
On Mon, Jul 24, 2000 at 08:18:16PM -0500, William A. Rowe, Jr. wrote:
> to both Greg and Ryan:
> > From: Greg Stein []
> > This is actually a very cool patch and it allows us to begin 
> > to do some "real" work with the filtering code.
> [snip]
> > In a word: Coolness
> You have -no- idea how glad we new-httpd-watchers are for you two to
> have worked out a patch that you can both accept :-)


> I know you have both looked to the list for significant feedback on
> your respective designs, and we are happy to oblige.  Seeing that you
> both feel you -need- specific issues handled by filtering, though,
> you two are absolutely in the best position to argue the merits and
> come to a common perspective (not to slight Dean, Roy, or other key
> architects of Apache!!!)  But when you two can dovetail into an
> acceptable solution, we have the battle won :-)

Well, this is a step towards filtering. Ryan and I spoke on the phone last
night (we missed each other at the conference) and talked through a number
of items about filtering.

[ yes, we spoke :-) ... it isn't like I've got a letter bomb on the way to
  his house or anything... really. honestly. you can trust me. ]

While this is a nice step, there are still a few outstanding issues about
filter models that we haven't quite resolved yet:

1) what is the lifetime of an ap_bucket_t (and/or a list/brigade of them)
   specifically: are they self-managed or do they die when the filter
   function returns? this also involves things like the use of malloc()

2) do we include a tail pointer? is this tail pointer in a separate
   structure or is it part of the actual bucket somehow? (e.g. the first
   bucket's prev pointer refers to the tail)

3) how do we read chunks of data out of a list of buckets? for some buckets
   this will implicitly "damage" the bucket (e.g. a bucket may refer to a
   pipe; once you read data, you can't stick it back into the bucket; you
   must build a new bucket to hold any pipe data you wish to keep) Part of
   this issue relates to Roy's concern about losing information on the
   origination of the data (does the ptr/len refer to a shared working buf
   or can you construct new buckets referring to the data)

There are probably a couple other issues, but I think the real stickler is
issue #1. That issue pretty much defines the difference between the filter
designs that Ryan and I have proposed. The rest (e.g. the recent patch for
filter registration) is basically window dressing.

If a bucket has a self-defined lifetime, then the ap_bucket_t must be
allocated from the heap/pool. Usually, its data must also be managed in a
way that is separate from the execution stack (e.g. rmem buckets have issues
in that they can refer to stack-based data; that prevents their self-
defined lifetime). These types of buckets can be easily set-aside, but they
can also create a situation of "copying earlier rather than later." I tend
to believe that they're harder to work with because you need to explicitly
manage their lifetime. The presence of rmem buckets means that a function is
always needed to "convert" the bucket into something that can be set aside.
Some buckets are no-ops (rwmem is the only one so far), while others may
need to copy rmem data, or "dup" a file handle. If the filter function is
always going to call a "convert" function, I would prefer to see the
execution-based lifetime (which can alter the buckets' lifetime at that

In any case... these final few issues will be handled a bit separately from
the registration issue emboded in this recent patch.

[ note that I'm out of town for a week; Ryan said he's busy, too; the rest
  of the stuff will be picked up next week. ]


Greg Stein,

View raw message