httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From r..@covalent.net
Subject Re: cvs commit: apache-2.0/src/main http_protocol.c
Date Thu, 12 Oct 2000 19:21:02 GMT

> > 2 is a scary design, because it allows two filters access to the same
> > brigade at the same time.  Sooner or later, we will clobber data that way.
> 
> ummm, I don't see a problem here.  I'm not scared at all.  If it really
> was the "same time" then it would be harder.
> 
> Only a single thread can access a bucket brigate or filter chain as
> implemented today.  We don't have any problem passing brigades between
> filters in the forward direction.  Why would we all of a sudden have
> problems passing them backwards?  Assuming of course that we use a
> pointer that belongs to the thread, or a callback, or a different
> function pointer in the filter structure for the pushback/unget brigade
> routine, or...  (plug in your favorite technique here)
> 
> What am I missing here?  I didn't get enough sleep last nite, but I did
> think about this stuff when I was well rested.

Passing brigades in one direction is easy, because when one filter passes
the brigade, it essentially says I am done with this data, I don't need it
anymore.  Passing brigades in two directions may be possible, IFF we use
function arguments to pass the brigades.  Having one filter put the
brigade in another filter's storage space is ugly, because you will never
know if the second filter has something else stored there.  The original
patch that you and Jeff created had two filters storing things in the
conn_rec structure.  But the problem is that it is impossible to know who
stored the data there are why.  To do that requires state, which wasn't
implemented, and would get ugly quickly.

The problem with passing data back through arguments, is that you don't
know which filters have been called already.  Think of it this way.  We
have a gunzip filter, which takes a bunch of compressed body data, and
uncompresses it.  Now, a higher filter decides to pass that data back
down, if it goes through the uncompress filter, then that filter can stop
the pass-back, but wait what if the data need to  go further than the
uncompress filter.  So, it really can't stop the pass-back, because that
could be a bad idea.  Okay, so it goes as far as it needs to.  Now, that
data is passed back up through the stack to the uncompress filter, but
it's already been uncompressed.  Uncompressing it twice is likely to give
us garbage.

Another possibility with the same example, is that we pass too much data
through the uncompress filter the first time, and we try to uncompress
header data.  That just won't work.

Passing data in one direction works because the filter says "I am done, I
never need to see this again".  Passing data in two directions means
either the design or the modules need to be much more complex.  It just
can't be done with the current design.  Either way, we make it harder to
write input filters, which isn't a good idea.

> > 3 is what we are implementing.  Basically saying, http_filter understands
> > two modes, but not when we are in each mode.  We tell http_filter which
> > mode we are in by the arguements we pass to it.  This is just like using
> > c->remaining, except it is safer.
> 
> I think this is OK for now, but the global argument passing thing is
> pretty shaky.  Sure, I love the concept of parameters.  But since we
> don't have a clean way today to target a specific filter with a specific
> dynamic parameter, the "one length argument applies to all filters"
> approach means that we can't implement any input filters that increase
> the length of the content.  gunzip, multi-byte charset xlation, ... 
> Once one filter increases the length of the data, what should the next
> filter upstream do with the length argument?  How would you implement
> those input filters in a general fashion?

The solution is to use an integer pointer instead of an integer in the
filter function argument list.  Basically, on input we are specifying the
maximum amount that we will allow to be READ, not returned, but read.  If
the filter changes the data, then the length has to grow, and the filter
has to inform the caller of this.

This is not how the code is written currently, but it is a simple change
if people agree.

Ryan

_______________________________________________________________________________
Ryan Bloom                        	rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------




Mime
View raw message