Skip to content

Flushing the multithreaded implementation is different from the single-threaded implementation. #230

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

Open
rhpvorderman opened this issue May 16, 2025 · 1 comment
Labels
bug Something isn't working

Comments

@rhpvorderman
Copy link
Collaborator

See pycompression/xopen#171 (comment)

@rhpvorderman rhpvorderman added the bug Something isn't working label May 16, 2025
@rhpvorderman
Copy link
Collaborator Author

rhpvorderman commented May 16, 2025

The normal implementation uses Z_SYNC_FLUSH.

From the zlib manual

If the parameter flush is set to Z_SYNC_FLUSH, all pending output is flushed to the output buffer and the output is aligned on a byte boundary, so that the decompressor can get all input data available so far. (In particular avail_in is zero after the call if enough output space has been provided before the call.) Flushing may degrade compression for some compression algorithms and so it should be used only when necessary. This completes the current deflate block and follows it with an empty stored block that is three bits plus filler bits to the next byte, followed by four bytes (00 00 ff ff).

So this data can be decompressed using deflate raw blocks. Which is useful to know for testing the correct flush behaviour. Sync flush ends the deflate stream and may influence the compressed size because of that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

1 participant