-
Notifications
You must be signed in to change notification settings - Fork 82
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
Decoder might block if there is data remaining to be flushed from the codec and the stream blocks #123
Comments
I encountered this issue when keeping an open connection, while not sending data. This caused the remaining data to be kept in the decoder. I have fixed the issue, but will try to write a test case. |
could you, please, review and merge this PR? |
robjtede
pushed a commit
that referenced
this issue
Sep 19, 2023
robjtede
pushed a commit
that referenced
this issue
Jan 17, 2024
robjtede
pushed a commit
that referenced
this issue
Jan 17, 2024
github-merge-queue bot
pushed a commit
that referenced
this issue
Jan 17, 2024
flush data still available in the decoder when no input (#123)
Seems |
link2xt
added a commit
to link2xt/async-compression
that referenced
this issue
Oct 9, 2024
… read Unlike zlib, miniz_oxide consumes data into internal state even if there is not enough space in the output buffer. Next time poll_fill_buf() is called we should try to decode from internal state even if no new compressed data was read. This change is a port of fix <Nullus157#123> (commit Nullus157@22ed0ac) from `futures` to `tokio`.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
See gyscos/zstd-rs#119, I'm pretty sure the local
bufread::Decoder
implementations suffer from this same issue. My first attempt at writing a test case failed to fail though.The text was updated successfully, but these errors were encountered: