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.

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

Non-blocking handling in gzread #992

Open
drbitboy opened this issue Jul 18, 2024 · 4 comments
Open

Non-blocking handling in gzread #992

drbitboy opened this issue Jul 18, 2024 · 4 comments

Comments

@drbitboy
Copy link

Caveat

I am new to zlib development; pehraps this has been brought up before and found to be insoluble; if so, please forgive me and feel free to delete this issue.

Background

The functions gzread/gzwrite are a sweet pair of near-analogs for read(2)/write(2), respectively (I was trying to re-invent their wheels over the past several weeks until I stumbled onto them ;-).

I am hoping to compress a stream of multiple XML entities (INDI protocol; see github.com/magao-x/MagAOX) with zlib, and gzread/gzwrite look like a nice way to do that since they handle all the intermediate buffering. The INDI server handles multiple connections, using select(2) and non-blocking I/O.

Issue

Of course gzread works as designed, but it does depend on the compressed stream not being non-blocking, so the read(2) will block when expected data are not yet available, so a return value of 0 can be interpreted as the other end closing the file descriptor i.e. EOF.

If the compressed stream is non-blocking, then a read(2) could return a status code of -1* with errno equal to EAGAIN or EWOULDBLOCK, for the case where the next data are not yet available e.g. TCP socket, which is normal, which would be interpreted by the current code develop//ceadaf2/gzread.c/line27 as an abnormal problem and pass the -1 return up the call chain, which would stop the decompression.

* N.B. this should not be possible if the stream is blocking, so the proposed PR does not affect gzread in that case.

PR

I will make a pull request from drbitboy/zlib-drbitboy.git, branch develop-20240718-drbitboy to madler/zlib branch develop. It's a very small change at this point, but I think it is only the initial step in making what I want to do work, so even if it makes sense don't merge it yet.

The biggest concern here would be if my eventual PR breaks existing applications; the minor change to this point should not do that, but who knows what else will be necessary; in that case I think special-purpose routines in gzread.c to handle non-blocking I/O would be the best path.

Best regards,

Brian T. Carcich
Latchmoor Services, INC.

@drbitboy
Copy link
Author

PR is #993

@drbitboy
Copy link
Author

drbitboy commented Jul 21, 2024

PR is #993

Seems to work now (drbitboy@6e8ddfd); needs a little cleaning up (comments), and I plan to write a test for it.

Let me know if there is anything else you want to see before starting a formal review.

@drbitboy
Copy link
Author

Test added for the new code; PR should be ready to merge. lmk, thanks!

@drbitboy
Copy link
Author

I have used these changes to add compression to the MagAOX repository; see PR drbitboy/MagAOX#8.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant