On Mon, 2018-02-26 at 21:06 +0100, Samo PogaÄ?nik wrote: > Dne 26.02.2018 (pon) ob 11:49 +0200 je Tanu Kaskinen napisal(a): > > On Sat, 2018-02-24 at 17:41 +0100, Samo PogaÄ?nik wrote: > > > > > > Added option auto_drain_pipe_on_resume to enable draining any > > > remaining > > > data from the pipe upon every pipe-sink resume out of suspend. > > > --- > > > src/modules/module-pipe-sink.c | 37 > > > ++++++++++++++++++++++++++++++++++++- > > > 1 file changed, 36 insertions(+), 1 deletion(-) > > > > I didn't review the patch yet, I just wanted to point out that the > > commit message doesn't explain what problem the patch solves. What's > > your use case? > > > > When a pipe reader fails, the pipe sink fills up the pipe and starts > dropping instead of writing new data. Old data remains in the pipe to > be consumed by the eventually recovered or replaced reader. By each new > drop a gap between the pipe content and new data to be written grows. > If the sink suspends while dropping, resuming from suspend is going to > clear the pipe and start writing new data into an empty pipe, thus > removing the gap (old, potentially irrelevant data). > > I had also prepared a supplementary change (not yet posted), which > enables the pipe to auto-leak at the consumers end, whenever a pipe is > full. When a pipe is full, the size of the unwritten data is first read > to make room for the repeated write. This way dropping would be > replaced by leaking and the pipe always contains latest data > independent of when a real consumer reader get started, stopped or > replaced, ... However, i am not sure how to preserve content format, > if necessary. > > I thought at some point, that this second change might be sufficient, > however it makes sense (in terms of pipe content relevance and data > processing time) to drain the whole pipe upon each resume from suspend. Thanks for the explanation, makes sense. Can you add the information to the commit message as well? -- Tanu https://liberapay.com/tanuk https://www.patreon.com/tanuk
