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. >>>
