> -----Original Message----- > From: Jim Jagielski [mailto:j...@jagunet.com] > Sent: Montag, 8. September 2014 21:31 > To: dev@httpd.apache.org > Subject: Re: [Patch] Async write completion for the full connection filter > stack > > Another consideration: We now have the "idea" of a master > and slave connection, and maybe something there would > also help... > > FWIW: I like using an empty bucket conceptually since it should > be ez and quick to check.
Agreed, but I think from design perspective using the empty brigade is a side effect we assign to it that is not immediately jumping at your eyes especially if you are "just" developing modules. Thinking the below further we might need some kind of "advisor" API for the filters that tells how much data they should consume to avoid buffering too much and how much they can send down the chain without ending up in a blocking write. How much buffering is advised could be set by a configuration directive. Regards Rüdiger > On Sep 8, 2014, at 2:53 PM, Ruediger Pluem <rpl...@apache.org> wrote: > > > Wouldn't it make more sense instead of using an empty brigade to create > yet another metabucket that signals write > > completion? It could also contain information how much data to send down > the chain for single filters if they e.g. send > > heap or transient buckets. Otherwise how should they know? > > If you have a filter that has a large file bucket set aside and it does > transform it e.g. to a heap bucket during it's > > processing because it changes data on it I guess it doesn't make sense > if it does send all stuff once it gets triggered > > for write completion as we would end up in a blocking write then in the > core filter. But if it knows how much is left in > > the core filter buffer it could try to just sent this and avoid thus > blocking writes. And if there is no room left in > > the buffer or if what is left is too small for the filter to operate on > it, the filter could just pass the bucket down > > the chain and if it would end up in the core output filter, the core > output filter would just try to write what it has > > buffered. > > > > > > Regards > > > > Rüdiger > > > > Jim Jagielski wrote: > >> Gotcha... +1 > >> On Sep 8, 2014, at 11:29 AM, Graham Leggett <minf...@sharp.fm> wrote: > >> > >>> On 08 Sep 2014, at 3:50 PM, Jim Jagielski <j...@jagunet.com> wrote: > >>> > >>>> This is pretty cool... haven't played too much with it, but > >>>> via inspection I like the implementation. > >>>> > >
