> On Wed, Mar 06, 2002 at 11:42:11PM -0800, Greg Stein wrote: > > apr_bucket_read(NONBLOCK) > > if (got_nothing) > > do_some_work > > flush_some_buffers > > apr_bucket_read(BLOCK) > > process_buckets() > > > > > > In other words, you could see if you have some work to do. If not, then > you > > go off and flush out other stuff that was pending. (that is: take > advantage > > of idle time) Once you're done with the work, then you go ahead and > block > > to get more work. > > You are correct, and this pattern is used twice only in mod_include. > > It seems to me that this pattern would tend to double the amount of > system calls to read, while only being successful with fast clients. > I would have to do some testing, but I suspect that we're not actually > improving data processing/response time but are instead increasing > system time. Just a hunch though...
It depends on what you are doing in between the first read and the second. The original conversation around filters only discussed non-blocking in terms of being able to pass the brigade faster. So, the conversation was always: apr_bucket_read(NON_BLOCK) If (got_nothing) Do some stuff Ap_pass_brigade() Apr_bucket_read(BLOCK) If you are passing a bunch of data to be written to the network, then the streaming effect outweighs the system time cost, because the user feels like they are getting the data faster. Of course, that logic doesn't work if you aren't putting a pass_briade inside the if clause. :-) Ryan