httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <gst...@lyra.org>
Subject Re: PLEASE READ: Filter I/O
Date Fri, 23 Jun 2000 10:19:13 GMT
On Thu, Jun 22, 2000 at 08:29:01PM -0700, Greg Stein wrote:
> On Fri, Jun 23, 2000 at 03:33:05AM +0100, Tony Finch wrote:
>...
> > I don't understand what the problem is here either. The 100MB example
> > doesn't seem very useful to me because presumably it's up to whatever
> > code retreived it from the database to decide how much to keep in core
> > at once, and whether it's a top-level handler or a greg-filter or a
> > ryan-filter it can be either simple or efficient.
> > 
> > I do wonder, Greg, how your scheme avoids excessive copying between
> > each filter layer...

Crap. I didn't answer that last part :-) ... here goes:

Each filter function is defined to take a pointer/length pair. That data is
from the "content generator" or it is from a previous filter. That ptr/len
pair can be passed directly to the next layer without copying.

For example:

ap_status_t my_filter_callback(ap_layer_t *layer, const void *buf, size_t len)
{
    ap_lwrite(layer, buf, len);
    return APR_SUCCESS;
}

Kind of a dumb, no-op filter :-), but it shows how data doesn't have to be
copied. Of course, the filter can parse stuff out, send portions, etc.
Sending a portion doesn't require copying:

    ap_lwrite(layer, (const char *)buf + 5, 5);


Is there something else that you were thinking of, or did I answer the
question?

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/

Mime
View raw message