apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From r..@covalent.net
Subject Re: [PATCH] brigade buffering.
Date Thu, 25 Jan 2001 23:09:58 GMT

> >However, you are correct that in general this is an issue, the 
> >solution is to always copy the data, but that has other 
> >drawbacks.  So, there are two answers to this that I see.  #1, tell 
> >the programmer that (s)he is out of luck if (s)he doesn't understand 
> >the code.  #2, actually copy all the data.
> >
> >I have no problem telling the programmer they are out of luck, this 
> >is open source after all.  I dislike copying the data, because it 
> >means we could chew a lot of memory very quickly.
> 
> So then the rule has to be that if call a apr_brigade_* function that 
> can generate more than APR_BUCKET_BUFF_SIZE data in a single call, 
> then that brigade has to be output before the buffer is reused or 
> goes out of scope?
> It's hard to see how that fits well into a general brigade API.

It's a trade-off.  I'm not saying this code is correct, this is the
first-stab, and it is a general idea or design.

> Would a better solution perhaps be that the apr_brigade_* functions 
> will always copy the data, and leave it up to the ap_f* functions to 
> provide the optimization of using the bucket API directly for large 
> blocks of data?  That seems to be a much safer way of doing things.

Copying that much data could be a real PITA, but yes that might make more
sense.

> One other optimization that I noticed would probably be useful would 
> be to have apr_brigade_putstrs written at the same level as 
> apr_brigade_write such that you save the memcpy of apr_brigade_write 
> after the apr_vsnprintf.

You lost me here.  I am not at all worried about optimizations right
now.  This code was a first stab, and a general design, and that's it.  My
biggest problem with this paragraph, is that apr_vsnprintf doesn't have
anything to do with apr_brigade_putstrs and apr_brigade_write, so I don't
see the connection.

Ryan

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




Mime
View raw message