Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Decoder might block if there is data remaining to be flushed from the codec and the stream blocks #123

Closed
Nemo157 opened this issue Jun 3, 2021 · 3 comments · Fixed by #247 or #294
Closed

Decoder might block if there is data remaining to be flushed from the codec and the stream blocks #123

Nemo157 opened this issue Jun 3, 2021 · 3 comments · Fixed by #247 or #294

Comments

@Nemo157
Copy link
Member

Nemo157 commented Jun 3, 2021

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.
@nl5887
Copy link
Contributor

nl5887 commented Sep 23, 2021

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.

nl5887 added a commit to nl5887/async-compression that referenced this issue Sep 23, 2021
@nl5887
flush data still available in the decoder when no input (Nullus157#123)
c634ad9
@Nemo157 Nemo157 mentioned this issue Aug 24, 2022
Open
@Geal Geal mentioned this issue Oct 12, 2022
Open
@fr3akX
Copy link

fr3akX commented Sep 19, 2023

could you, please, review and merge this PR?

@robjtede robjtede mentioned this issue Sep 19, 2023
Closed
robjtede pushed a commit that referenced this issue Sep 19, 2023
@nl5887 @robjtede
flush data still available in the decoder when no input (#123)
9e81bf2
robjtede pushed a commit that referenced this issue Jan 17, 2024
@nl5887 @robjtede
flush data still available in the decoder when no input (#123)
98eae35
@robjtede robjtede mentioned this issue Jan 17, 2024
Merged
robjtede pushed a commit that referenced this issue Jan 17, 2024
@nl5887 @robjtede
flush data still available in the decoder when no input (#123)
22ed0ac
github-merge-queue bot pushed a commit that referenced this issue Jan 17, 2024
@NobodyXu
Merge pull request #247 from Nullus157/fix-123
6e3996d 
flush data still available in the decoder when no input (#123)
@link2xt link2xt mentioned this issue Oct 8, 2024
Merged
@link2xt
Copy link
Contributor

link2xt commented Oct 8, 2024

Seems tokio implementation was not fixed, started to fix it in #294 in a different way and then discovered this change.

link2xt added a commit to link2xt/async-compression that referenced this issue Oct 9, 2024
@link2xt
fix(tokio): attempt to decode from internal state even if nothing was…
ed83d67 
… 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
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
4 participants
@Nemo157 @fr3akX @nl5887 @link2xt