> 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
