On Monday 23 January 2012, Joe Orton wrote: > On Sun, Jan 22, 2012 at 12:12:09PM +0100, Stefan Fritsch wrote: > > On Friday 20 January 2012, Joe Orton wrote: > > > If we assume that morphing buckets cannot be buffered, the code > > > could be adjusted to always place them in the "to flush" > > > segment, and then there is no need to read the buckets until > > > they need to be sent, as in the patch below. This seems to > > > fix the memory consumption behaviour without obviously > > > breaking anything else (cough cough). > > > > > > > > I think that your patch is correct. However, as an optimization, > > one could try reading the morphing bucket until there are > > THRESHOLD_MAX_BUFFER bytes in memory. If all morphing buckets in > > the brigade disappear before reaching that limit, one could > > still do async write completion. > > The blocking behaviour does matter here. If the brigade contains > 60K of HEAP buckets and then a morphing bucket, the core must > have written out the HEAP buckets before it attempts a blocking > read on the morphing bucket. The usual style is per: > > http://httpd.apache.org/docs/trunk/developer/output-filters.html#no > nblock > > The current behaviour is a regression back to early 2.0.x, PR 8482. > > > I don't think so. AFAIK, there is no way for an async mpm to poll > > on more bytes from the producer bucket. If the network to the > > client is faster than the producing cgi, a non blocking read > > would only put a few (or even zero) bytes in the output buffer, > > the output socket would immediately become writable again, and > > the output filter would be called again. This would cause a busy > > loop, wasting CPU cycles. If my assessment is correct, this > > should go as a comment into send_brigade_nonblocking(). > > I think I was not clear enough here: yes, the non-blocking read > must be followed by blocking reads.
Right, that makes sense.
