httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Winstead <j...@trainedmonkey.com>
Subject Re: summary: issues for my filtering patch
Date Wed, 28 Jun 2000 18:17:16 GMT
On Jun 28, rbb@covalent.net wrote:
> 
> > > 2)  The core imposes some sane restrictions on how much of the request is
> > > in memory by controlling the buffering.
> > > 
> > > Greg is proposing #1, I am proposing #2 (after much prompting and head
> > > beating from Roy).  My feeling, after having looked at this problem for a
> > > VERY long time, is that trying to just fit option 2 in after the current
> > > patch is applied is almost impossible.
> > 
> > What are the restrictions imposed by the core in this scheme?
> 
> Basically, the core will provide buckets, which can get so big.  If the
> buckets get too big, the buckets themselves flush out to the disk, and
> shrink.

This is probably a dumb question, but how does a bucket grow?

> Allowing people to hang themselves, and not providing a way to prevent
> them from hanging themselves are two VERY different things.  Yes, if
> somebody wants to write a filter that takes down the server, then they
> will.  If we don't provide a sane bucket scheme, then ANYBODY who writes a
> filter has a very good chance of taking down the server.

Agreed. I just don't want to see anyone slip into the mentality
"this must be perfect in all situations" before the patch gets
commited and people really dig into using it.

> Defining the life cycle of the bucket to end when the bucket is sent to
> the network doesn't have anything to do with single or zero copy.  The
> problem is that in the current patch, no information about the memory is
> passed with the memory.  This means that each filter must assume the
> memory cannot be touched.

Got it. This was the piece I was missing.

> Basically, what I was getting at was that if the first filter that needs a
> copy of the data makes a copy and marks it as modify-able memory, then no
> other filter in the stack needs to make a copy, because it can just modify
> it in place.

That makes perfect sense. It also seems like that should be relatively
trivial to add. (Buckets just need to implement a "give me the
pointer to a modifiable version of the contents" method, and
depending how the bucket was allocated, the right magic can happen.
Just like a bucket may need to register a cleanup function for
itself that knows how to free any resources it is using, like
calling mysql_result_free.)

But maybe Greg's patch is further away from the ADT-style implementation
of buckets than I'm assuming.

> PHP can add it's own buffering in, there is nothing to stop that and there
> is no reason to.  What we want to keep from happening, is to make EVERY
> SINGLE filter implement their own buffering.

I'd rather have every filter implement its own buffering than not
have filtering. But I don't think that anyone is saying that
providing a way for that buffering to happen in a standard way is
not highly desirable (and even a prerequisite for releasing 2.0 if
filtering is a part of 2.0), just that it doesn't have to be a
prerequisite for the filtering work to start going into alpha and
beta releases so people will really dig into it.

You can only imagine so many scenarios and draw so much on a white
board to solve them. Sometimes it is tremendously useful to actually
start down the path to encounter the real roadblocks.

Jim

Mime
View raw message