RE: APR_BUCKET_BUFF_SIZE question
This is the same issue I was dealing with in mod_proxy that I submitted the patch for in 'BUG 19954 [PATCH] HTTP tunneling through reverse proxy does not always work'. In my case I didn't care what the read size was, but I needed to forward on whatever had been read, even if it was less than 8000 bytes. Obviously, the patch I submitted was specific to mod_proxy, but the root issue is the same. - Chris Conti [EMAIL PROTECTED] [EMAIL PROTECTED] The buffer size is not 8K... it's 8000. 8K is what's actually allocated, ... I still don't see what problem you're trying to solve, though, by wanting a configurable buffer size? --Cliff
Re: APR_BUCKET_BUFF_SIZE question
On Wed, 9 Jul 2003, Juan Rivera wrote: That way a filter could ask for more or less bytes than the 8K. That's what apr_brigade_partition() is for. Does that not get you what you want? And anyway, having a runtime-configurable buffer size would make the bucket allocator WAY more complicated and less efficient... --Cliff
Re: APR_BUCKET_BUFF_SIZE question
Juan Rivera [EMAIL PROTECTED] writes: [...] That way a filter could ask for more or less bytes than the 8K. A filter can ask now- it just won't get more than 8K per ap_get_brigade call. FWIW, I think the best approach would be to put a loop in httpd-2.0/server/core.c's core_input_filter(), that would at least provide the core input filter with the ability to yield brigades with more than one (8K) bucket. -- Joe Schaefer
RE: APR_BUCKET_BUFF_SIZE question
Title: RE: APR_BUCKET_BUFF_SIZE question I figured it has to do something with the way pools work. Would it make a difference if the buffer size used is always a multiple of APR_BUCKET_BUFF_SIZE? Like 16, 32, 64? Do you know where the 8K number come from? Is it an empirical number or a theoretical one? -Original Message- From: Cliff Woolley [mailto:[EMAIL PROTECTED]] Sent: Wednesday, July 09, 2003 6:25 PM To: '[EMAIL PROTECTED]' Subject: Re: APR_BUCKET_BUFF_SIZE question On Wed, 9 Jul 2003, Juan Rivera wrote: That way a filter could ask for more or less bytes than the 8K. That's what apr_brigade_partition() is for. Does that not get you what you want? And anyway, having a runtime-configurable buffer size would make the bucket allocator WAY more complicated and less efficient... --Cliff
RE: APR_BUCKET_BUFF_SIZE question
On Wed, 9 Jul 2003, Juan Rivera wrote: I figured it has to do something with the way pools work. Nope, buckets don't allocate anything from pools. Would it make a difference if the buffer size used is always a multiple of APR_BUCKET_BUFF_SIZE? Like 16, 32, 64? Lots of the code assumes that things will be done in APR_BUCKET_BUFF_SIZE increments at the most. If you go in multiples of that, it means multiple buckets. The reason is that the bucket allocator hands out 8KB blocks. One of them it carves up into little hunks (I forget how big little is exactly, but it's something on the order of 64 bytes), and the others it hands out as-is. Do you know where the 8K number come from? Is it an empirical number or a theoretical one? The buffer size is not 8K... it's 8000. 8K is what's actually allocated, but some of that is used internally by the bucket allocator. The reason is that 4KB or 8KB tend to be the size of VM pages. We went with 8KB to try to balance computational overhead with memory overhead. I still don't see what problem you're trying to solve, though, by wanting a configurable buffer size? --Cliff
