Change was done in http://svn.apache.org/viewvc?view=revision&revision=327872 by brianp in 2005 with message:
"New version of ap_core_output_filter that does nonblocking writes (backport from async-dev branch to 2.3 trunk)" Since Brian put his name in CHANGES, it was probably him... -Stefan > Am 27.04.2016 um 14:52 schrieb Graham Leggett <minf...@sharp.fm>: > > On 27 Apr 2016, at 2:49 PM, Stefan Eissing <stefan.eiss...@greenbytes.de> > wrote: > >> I had a look into 2.4.x this morning and while there are changes in filter >> brigade setaside code, the basic "cleanup" of empty and meta buckets before >> the setaside is there already. >> >> I think this has not bween noticed before as >> 1. EOR is always followed by a FLUSH >> 2. most bucket types survive the destruction of r->pool quite well, even >> pool buckets silently morph >> 3. even if transient buckets would reference pool memory, settings those >> aside after destruction of r->pool, but before filter return would access >> freed, but not re-used memory from the connection allocator - I think. >> >> So far, I have seen no reasons why meta buckets should not just be setaside >> in core filter. 0 length data buckets should also stay, IMHO, just ignored >> in the actual write. >> >> I can only guess the original intent: 0-length data buckets sometimes happen >> during some brigade read modes and if there are several FLUSH buckets in the >> brigade, it makes sense to get rid of them also. But I think the space >> savings are minimal. >> >> But there could be reasons for the current behavior, I overlooked. So, I am >> asking around. > > I don’t see any obvious reason for the current behaviour either - is it > possible to go back in history and confirm the log entry when it was > introduced? > > Regards, > Graham > — >
