httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From r..@covalent.net
Subject Re: [PATCH] buckets: appending to a bucket_brigade (untested)
Date Thu, 13 Jul 2000 02:28:42 GMT
On Wed, 12 Jul 2000, Cliff Woolley wrote:
> >>> rbb@covalent.net 07/12/00 19:20 PM >>>
> >Cliff, GREAT!!!!!!  Thanks for the patch.  I'm
> >unlikely to review and
> >apply this tonight, but I should get to it tomorrow.
> 
> Cool.  There's one other side-effect of the patch that I forgot to
> mention before, and I don't know if it's what you want or not.  I
> removed the ap_bucket_list_init() function, since it seemed to be
> unnecessary now that ap_bucket_list_create() uses calloc() instead of
> malloc().  <shrug>  I couldn't think of any reason that we ever want to
> reuse a bucket_list and therefore want to re-init it... anyway, if you
> really do want that function still, just take that part of the patch out
> and it shouldn't affect anything else in the patch.

No, that function does need to go away.  I haven't reviewed the patch, but
I hope to do it early tomorrow morning.  

> I've got a pretty good line on where some of the memory leaks are... I
> should be able to submit another patch after I see your next rev. in
> CVS.

Great, I look forward to it.

> 
> (PS: sorry I can't really test this stuff even for compilability... the
> hard drive on my development box crashed the other day <sigh>, and I
> haven't gotten a chance to replace it yet.)

If you want to keep feeding me patches, I'll review and commit them when
possible.

> >I had a vague idea that there were memory leaks, but
> >I haven't really looked into them yet.  I want to get
> >the basic code working to prove the
> >design, and then go back and clean it all up.
> 
> I know.  I'm just trying to help clean up, since I know you're working
> on fleshing it out.  I think I saw at least one more "this doesn't work"
> comment... I'll try to look into repairing that function tomorrow
> morning.  If you can think of any other clean-up or even
> API-implementation-type things that someone like me could be working on,
> by all means just say so.

Cool.  I've been trying to document things that need doing as I skip over
them.  :-)  Keep looking at the code to find where things need work
done, that I know about.

> I do have one general design question... I don't really understand why
> in some cases it would be necessary to shuffle a bucket out to disk. 
> There's at least oe comment in the code that says that situation exists
> in some case or another.  What if we have less disk space to work with
> than RAM?  (That's not an unusual situation where I work <grin>.)  Or
> have I missed the point?  Just curious.

The thought is that we don't want modules to keep the entire request in
memory at one time.  If a module wants to buffer the entire request (to
modify a header for example), then we only let it keep a certain amount of
that in memory at any one time.  In the current code I believe the
memory limit is 8K, but I could be wrong about that.  In fact, the limit
may not exist in the current code.

Once that much memory is used in a single request, the memory all gets
flushed to disk, and we can allocate more memory.  If that doesn't explain
it, let me know and I'll try to explain it a bit more.

Ryan


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



Mime
View raw message