httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Ames <grega...@raleigh.ibm.com>
Subject Re: cvs commit: apache-2.0/src/main http_core.c http_protocol.c
Date Mon, 02 Oct 2000 15:43:47 GMT
rbb@covalent.net wrote:

> > 1. It is easy to write a buffering filter without unnecessary copies
> > using the setaside facility, i.e. only TRANSIENT buckets would get
> > copied. What has been committed copies far too much unnecessarily,
> > and fails to allow for 3rd party bucket types.
>
> While this is true, Bill is also right.  Avoiding copying is a laudable
> goal, but it is just a goal.  It should not be the end all be all of our
> filtering.  There are times that copying is a good idea, and it is the
> correct design.
>
> The problem is that we need to be very careful how often we copy, and when
> we decide to copy.

If we are talking data that lives in memory, and the goal is to minimize CPU
cycles,
then it's not too difficult.  Just look at the size.  Below some threshold, it
will be cheaper to copy, assuming that there are multiple small pieces that can be
aggregated.

> I think 99% of this problem can be solved by putting
> some buffering in the ap_r* functions and by converting all of the current
> handlers to use the buckets directly.

Sorry, I can't parse that.  mod_autoindex has a handler which uses ap_r* functions
to write lots of tiny strings (or individual characters, like '\n') to the filter
chain.  Are you saying that the inefficiencies of doing this would go away if
mod_autoindex's handler used buckets to write directly to the filter chain?  And
who would use the ap_r* functions with the buffering?

If you meant to say that handlers like mod_autoindex which need buffering should
continue to use ap_r* functions, then it makes more sense.

In any case, I'm against a design philosophy that requires every module which
creates content (handler or filter) to write its own buffering layer.

Greg


Mime
View raw message