httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: [PATCH] buckets take 2
Date Thu, 18 Jan 2001 19:11:42 GMT

> 1. Something I'm confused about:
> In ap_rflush(), I don't understand why wewe need to do anything if
> r->bb is NULL.  r->bb==NULL means the ap_r* API hasn't been used to
> generate any output, so there is nothing to flush.

We still need to send the FLUSH bucket, because there may be something in
a later filter that was created using the pure bucket API.  This is really
just to make everybodies life MUCH easier.  We currently have modules that
require this behavior.

> 2. Something I'm not 100% sure of:
> Please verify: We reuse the buffers used for coalescing over the life
> of a certain response because once we call ap_pass_brigade() to flush
> the subpool from which the coalesce buffers is allocated will be
> released to the free chain maintained by apr_pools.c code.

No, we can't reuse the buffer.  Here's how I thought of it.  We have a 4K
buffer in the brigade, and we continuosly copy data into it.  When we call
ap_pass_brigade, that buffer is put directly into a POOL_bucket at the end
of the brigade.  The next time we call ap_r*, there is no garauntee that
the data has actually gone out over the wire, because a later filter may
be holding it up.  This does still allow us to chew up memory, but the
only solution to that, is to make the save_brigade call check the length
of the brigade and save to disk when it is too large.  What this patch
does do, is that it gets the data moving down the filter stack more
quickly, so chewing up memory is not as likely.  

> I'm pretty darn sure I'm +1 on the patch, but please eliminate my
> confusion.

No problem.  :-)

Ryan Bloom               
406 29th St.
San Francisco, CA 94131

View raw message