apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <gst...@lyra.org>
Subject Re: cvs commit: apr-util CHANGES
Date Mon, 23 Sep 2002 10:30:41 GMT
On Sun, Sep 22, 2002 at 07:00:42PM -0700, Brian Pane wrote:
> On Sun, 2002-09-22 at 16:34, Greg Stein wrote:
> All the copying doesn't bother me as much, because it's the same
> thing that would happen if you did a dozen calls to apr_brigade_write()
> for slightly less than APR_BUCKET_BUFF_SIZE bytes each.  So the copying
> overhead in this case would be no worse than apr_brigade_write().

That's not an argument :-)  You're only comparing brigade_writev() against
*prior* usage which did a bunch of _write() calls. So what?

If we code some new stuff using the new _writev(), then you've got a bunch
of copying occurring. And if the total size of your _writev() is going to
cause a flush, then you shouldn't do *any* copying. Just pass it to the
flush function and be done with it.

> > If you total up the number of bytes represented by the iovec, and that total
> > is more than APR_BUCKET_BUFF_SIZE, then simply create <nvec> TRANSIENT
> > buckets and flush the thing. No copies at all.
> That approach would create some different problems, though.  Consider
> a case where the vector consists of a few dozen small strings followed
> by a large buffer--for example, a lot of small bits of text comprising
> a response header, followed by a >8KB buffer containing the response
> body.  If we create two dozen transient buckets, we could end up doing
> extra copying: a copy per bucket if any filter tries to setaside the
> brigade, plus a copy in the core_output filter as it tries to combine
> the many tiny buckets into one larger buffer.

The setaside is not your problem. You cannot and should not guess what is
going to or *might* happen. The brigades are supposed to be about *avoiding*
copies. If/when a copy *must* be made, then fine. But don't make judgements
in advance because you *don't have the info*.

If the core_output filter is in use, then let it combine the small buckets.
Don't do it up front. There are too many other things that might happen, and
it isn't right to pre-judge.

If those little buckets bother you, then write an aggregation filter. But
you shouldn't be monkeying with the core functions because of suppositions
about how the system is set up or what it is going to do.

apr_brigade_writev() knows nothing about the core_output filter. And it
shouldn't. Buckets may or may not be set aside; hell... the brigades might
not even be involved in a filter chain!


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

View raw message