-
Notifications
You must be signed in to change notification settings - Fork 309
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
zstd: read blocking when unable to fill buffer #168
Comments
When decoding data needs to be available in blocks. This means it is impossible for the decoder to progress until an entire block is available. To force all data to be output, you can use the Flush function when encoding to force a block break at a specific point. |
Thanks for the quick response. I am using |
ok. I don't remember there being a buffer in the decoder. I can easily have forgotten it, though. |
I may be misreading, but this section appears to continue to try to read blocks until Lines 112 to 129 in 36d74a0
My applications stack trace shows it blocking on Line 344 in 36d74a0
So I don't confuse things, only my code is using a |
Ok, I see. Yeah - we don't know if Usually it will not. It should be fairly trivial to add a default select here that just whether data is available. Maybe change the signature to Calls from |
Fixed in master. Released as v1.8.6 |
Thank you! FWIW, I agree with:
The |
I ran into an scenario where my application would block when a
zstd.Reader
was wrapped with abufio.Reader
. When there was data available but less than the 4KB buffer thatbufio.Reader
useszstd.Reader.Read
appears to block waiting for more.I can work around this easily by not using a
bufio.Reader
or passing thebuio.Reader
tozstd.NewReader
, but I was wondering if my interpretation of the code sounds right to you and whether you intended this behavior.io.Reader
docs say "Read conventionally returns what is available instead of waiting for more" so it was slightly surprising but it's not a requirement so I wouldn't call this a bug.Thank you for all the work you've put into these compression libraries, they're really great!
The text was updated successfully, but these errors were encountered: