On Mon, 11 Jun 2001, Roy T. Fielding wrote: > But that's not thinking at a wide enough scope. There are lots of reasons > why I chose the analogy of "bucket brigades" for the original design, but one > is that we want to put the "fire" out. Web applications are very sensitive > to latency. The only way to get both network-efficient packets and avoid > suffering from unnecessary latency is to prevent more than a specific > amount of data from getting stuck in the filter chain. Sometimes that > isn't possible due to the nature of a filter (batch-like processing), > but in general we do not want to setaside anything but raw data, and only > then when it is less than 4KB. [Not 9000 bytes -- 4KB is more than > sufficient to justify a network write.] Even a cached file handle is > better copied to memory at that point if doing so avoids the need to > mutex a bunch of code. > > Maybe what we need is two functions,
I suppose that makes sense. > one for moving data to a preallocated buffer Except for the "preallocated" part, plain old read() fits the bill. I would say that's good enough, but I'm currently on a mission to get rid of as many malloc's as possible. So let's just suppose for a moment that we decided to implemented something new: I guess what you're asking for is a "read_into()" function? I could live with that. I don't know what exactly that would do to the brigade, but I imagine there's some something that could be done. Let's say we have a pipe bucket that we have to handle. If read_into() is called on that bucket, the brigade is busted unless we morph the pipe bucket simultaneously and allow the brigade to include a pointer to that arbitrary data. But it's hard to morph the bucket in this case, because the bucket doesn't "own" the storage, and therefore it's hard to know what bucket type to use. I guess when the bucket doesn't "own" the storage that's technically the textbook case for an immortal bucket, but I haven't yet convinved myself that that will work in this case. I'll have to think about this some more... > and another for setaside using a pool. The problem with a single > function is that buffering is very filter-specific. Yep. --Cliff -------------------------------------------------------------- Cliff Woolley [EMAIL PROTECTED] Charlottesville, VA
