On 03/27/2018 07:17 PM, Peter Xu wrote:
On Tue, Mar 27, 2018 at 03:42:32AM +0800, Xiao Guangrong wrote:
[...]
It'll be understandable to me if the problem is that the compress()
API does not allow the input buffer to be changed during the whole
period of the call. If that is a must, this patch for sure helps.
Yes, that is exactly what i want to say. :)
So I think now I know what this patch is for. :) And yeah, it makes
sense.
Though another question would be: if the buffer is updated during
compress() and compress() returned error, would that pollute the whole
z_stream or it only fails the compress() call?
I guess deflateReset() can recover everything, i.e, keep z_stream as
it is init'ed by deflate_init().
(Same question applies to decompress().)
If it's only a compress() error and it won't pollute z_stream (or say,
it can be recovered after a deflateReset() and then we can continue to
call deflate() without problem), then we'll actually have two
alternatives to solve this "buffer update" issue:
1. Use the approach of current patch: we copy the page every time, so
deflate() never fails because update never happens. But it's slow
since we copy the pages every time.
2. Use the old approach, and when compress() fail, we just ignore that
page (since now we know that error _must_ be caused by page update,
then we are 100% sure that we'll send that page again so it'll be
perfectly fine).
No, we can't make the assumption that "error _must_ be caused by page update".
No document/ABI about compress/decompress promised it. :)
Thanks!
